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ABSTRACT 


This  thesis  is  part  of  a  year  long  project  that  was  undertaken  by  NFS  students 
and  faculty  to  develop  a  system  architecture  and  migration  plan  for  the  transition  from  a 
legacy  information  system  to  a  cUenl/server  based,  open  information  system  for  the  Marine 
Corps  Institute  (MCI).  The  primary  objective  of  this  thesis  is  to  develop  the  technology 
architecture  required  to  support  the  information  systems  of  the  Student  Services 
Department  (SSD)  of  MCI  and  to  address  the  complex  issues  of  system  migration. 

This  thesis  conducts  an  analysis  of  existing  hardware  and  software,  defines  a 
technology  architecture  that  will  support  the  operational  requirements  of  the  data  and 
business  process  model  developed  by  other  team  members,  and  proposes  a  migration  plan 
to  transition  from  the  current  architecture  to  the  proposed  architecture  that  addresses  both 
technical  and  human  factor  issues. 

The  thesis  cui  inmates  in  specific  recommendations  for  MCI  with  regard  to  the 
hardware,  software,  and  migration  issues. 
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L  INTRODUCTION 


Many  organizations  have  initiated  efforts  to  migrate  from  their  current  outdated 
legacy  systems  to  open  system  architectures  that  support  flexible  business  practices  and 
take  better  advantage  of  emerging  technologies.  This  research  addresses  one  such  effort 
by  developing  a  techriology  architecture  for  a  target  hardware  and  software  platform  and  a 
migration  plan  to  traiv  ition  from  the  legacy  system  to  a  contemporary  system. 

A.  BACKGROUND 

The  Marine  Corps  Institute  (MCI)  was  established  to  "develop,  publish,  distribute, 
and  administer  distance  training  and  education  materials  to  enhance,  support,  or  develop 
required  skills  and  knowledge  of  Marines  and  to  satisfy  other  training  and  education 
requirements  as  identified  by  the  Commanding  General,  MCCDC."  MCI  is  the  primary 
distance  learning  activity  for  the  United  States  Marine  Corps.  The  ability  of  MCI  to 
perform  this  importar  t  mission  has  been  significantly  hindered  by  its  outdated  information 
system.  The  department  most  affected  by  the  deficiencies  of  the  current  system  is  the 
Student  Services  Department  (SSD). 

In  response  t(j  the  system  shortcomings,  and  in  order  to  improve  system  flexibility 
for  better  student  support,  MCI  initiated  a  project  to  redesign  and  modernize  their 
information  system  using  modern  development  techniques  and  an  open  hardware  and 
software  architecture.  In  addition,  MCI  is  also  reviewing  and  redesigning  their  business 
processes  to  better  support  its  mission  and  to  better  keep  pace  with  current  advances  in 
training  and  education. 
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B.  OBJECTIVE 


This  research  is  part  of  a  year  long  project  whose  overall  objective  is  to  migrate  a 
legacy  system  of  the  Student  Services  Department  (SSD)  at  MCI  to  a  contemporary 
client/server  open  system. 

The  primary  objective  of  this  research  is  to  develop  a  technology  architecture  to 
support  the  information  systems  of  SSD  and  to  address  the  complex  technology  and 
human  resources  issues  of  system  migration.  Fundamental  principles  guiding  the 
formulation  of  the  technology  architecture  are  developed  and  used  in  the  design;  the  “as 
is”  architecture  is  doc  c'mented  and  integrated  with  the  “to-be”  architecture  wherever 
possible;  and  strategie,-.,  concerns,  and  considerations  for  the  migration  of  the  current 
system  to  the  target  system  are  developed. 

C.  RESEARCH  QUESTIONS 

This  research  addresses  the  following  primary  research  questions: 

1.  Can  a  technology  architecture  be  developed  to  support  the  current  and  future 
needs  of  the  Student  Services  Department  at  the  Marine  Corps  Institute? 

2.  Can  existing  hardware  and  software  used  by  the  Student  Services  Department 
of  the  Marine  Corps  Institute  be  successfully  migrated  to  an  open  system 
architecture? 

In  addition,  the  follov/ing  subsidiary  questions  must  be  addressed: 

1.  Can  Enterprise  Architecture  Planning  support  all  the  necessary  requirements  of 
this  transition? 


2 


2.  What  is  the  current  state  of  the  Marine  Corps  Institute  Automated 
Informaticn  System  (MCIAIS)? 

3.  What  combinations  of  hardware  and  software  should  be  used  to  meet  new 
system  rei  piirements  within  the  given  fiscal  limitations? 

D.  SCOPE 

As  indicated,  this  research  is  part  of  a  large  project  aimed  at  the  development  of  a 
comprehensive  system  architecture  and  migration  plan  for  MCIAIS.  As  such,  this  thesis  is 
closely  coordinated  with  the  work  of  four  other  students.  These  students  are  conducting 
research  and  preparing  theses  related  to  the  development  of  the  business  processes  in 
SSD;  development  of  a  data  model  to  support  the  business  processes;  and  development  of 
a  Graphical  User  Interface  (GUI)  and  proof-of-concept  prototype. 

The  focus  of  this  research  is  on  documentation  of  the  cimrent  hardware  and 
software  environment.,  the  design  of  a  technology  architecture  to  support  future  hardware 
and  software  requirerrients,  and  development  of  a  migration  plan  to  transition  from  the 
current  system  to  the  future  system. 

The  scope  of  the  technology  architecture  and  migration  plan  presented  in  this 
research  is  limited  to  the  systems  in  use  by  SSD,  and  does  not  address  in  detail  the  system 
architecture  requirements  or  design  of  the  enterprise  system  for  MCI. 

E.  METHODOLOGY 

Two  distinct  methodologies  were  used  in  the  development  of  this  thesis.  The  first 
was  used  for  the  development  of  the  technology  architecture,  and  the  second  was  used  for 
the  development  of  the  migration  plan. 
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1.  The  Technology  Architecture 

The  first  methodology  used  in  this  thesis  is  based  on  Steven  Spewak's  Enterprise 
Architecture  Planning  model,  specifically  addressing  tasks,  timelines,  issues  for 
consideration,  and  the  philosophical  approach  of  the  definition  of  the  technology 
architecture. 

2.  The  Migration  Plan 

The  second  methodology  used  in  this  thesis  is  the  framework  of  system  migration 
developed  by  Brodie  and  Stonebraker.  This  methodology  is  referred  to  as  the  "Chicken 
Little  Approach,"  and  is  one  of  the  two  proposed  methods  of  system  migration  based  on 
actual  migration  efforts  that  are  documented  by  Brodie  and  Stonebraker.  The  "Chicken 
Little  Approach"  provides  an  incremental  method  for  implementing  a  contemporary 
system,  and  therefore  best  suits  the  MCI  environment. 

Background  information  and  specific  details  regarding  the  existing  architecture 
were  collected  through  interviews  with  key  MCI  staff.  Capabilities  and  requirements  to 
support  open  system  architectures  were  obtained  from  literature.  World  Wide  Web,  and 
personal  interviews  Vv-ith  NPS  staff.  System  requirements  were  obtained  from  interaction 
with  other  students  involved  in  the  MCI  project  and  responsible  for  the  development  of 
the  data  and  process  models.  The  primary  limitation  was  interaction  with  the  client,  and 
obtaining  required  feedback  in  a  timely  fashion,  due  largely  to  competing  priorities  and 
geographic  separation. 


4 


F. 


ORGANIZATION  OF  STUDY 


This  thesis  is  organized  to  address  the  objectives  of  the  study  in  six  chapters. 
Chapter  II  discusses  the  Enterprise  Architecture  Planning  (EAP)  methodology  in  detail, 
describing  the  four  layers  and  seven  components  of  the  methodology.  The  chapter 
concludes  with  a  discussion  of  some  of  the  issues  of  concern  for  planners  adopting  this 
methodology. 

Chapter  ID  provides  an  overview  of  the  current  system,  addressing  its  hardware 
and  software  environment,  peripherals,  networking  environment  and  applications.  It  then 
provides  an  overview  of  the  target  client/server  system. 

Chapter  IV  describes  the  actual  technology  architecture  for  MCI  as  it  was 
developed  under  the  EAP  methodology.  It  proposes  three  technology  platforms  options 
for  consideration,  and  analyzes  the  advantages  and  disadvantages  of  each. 

Chapter  V  presents  the  migration  plan  for  this  study.  It  provides  an  overview  of 
migration  planning,  a  discussion  of  the  strategies  and  constraints  of  system  migration,  a 
detailed  migration  strategy  for  MCI,  and  recommendations  concerning  migration. 

Chapter  VI  is  an  exploration  of  the  human  factors  affecting  this  transition  effort. 
The  transition  effort  is  analyzed  using  a  human  systems  framework,  and  the  issues  of 
change  management  for  this  project  are  explored  in  detail  with  recommendations  for 
improved  transition  management. 

Chapter  VII  contains  the  conclusions  and  recommendations  for  this  study. 
Appendix  A  contains  an  abbreviated  Information  Resource  Catalog  (IRC)  that  was  used  in 
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the  development  of  the  technology  architecture,  and  Appendix  B  is  a  system  map,  which 
depicts  the  connectivity  of  the  entire  information  system  at  MCI. 
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n.  ENTERPRISE  ARCHITECTURE  PLANNING  METHODOLOGY 


The  purpose  of  this  chapter  is  to  provide  the  reader  with  a  broad  overview  of  the 
methodology  used  in  developing  the  proposed  architecture  definition  for  the  replacement 
information  system  for  Marine  Corps  Institute  (MCI).  The  methodology  is  &st  discussed 
as  it  applies  to  the  enterprise  level,  then  specifically  as  it  applies  to  the  development  of  the 
technology  architecture.  The  methodology  outlined  in  this  chapter  is  adapted  from  the 
EAP  methodology  by  Steven  Spewak  [Ref.  1]. 

A.  ENTERPRISE  ARCHITECTURE  PLANNING 

The  greatest  difficulty  for  information  technology  (IT)  specialists  in  supporting  the 
business  needs  of  today’s  organizations  is  the  confusion  and  incoherence  of  the  planning 
process  [Ref.  1].  Enterprise  architecture  planning  (EAP)  is  a  methodical  attempt  to 
provide  a  stmctured  framework  for  the  conduct  of  effective  IT  planning. 

1.  Definition  and  Components 

Spewak  defines  enterprise  architecture  planning  as  “the  process  of  defining 
architectures  for  the  use  of  information  in  support  of  the  business  and  the  plan  for 
implementing  those  architectures  [Ref.  1].”  The  plan  is  to  cover  the  three  basic  types  of 
architectures:  data,  applications,  and  technology  architectures.  The  important  distinction 
drawn  by  this  methodology  is  that  of  definition  and  design.  Definition  of  a  system  is 
answering  the  question  of  “what”  for  a  new  system,  design  of  a  system  answers  the 
question  of  “how”.  EAP  is  used  for  the  process  of  architecture  definition.  After  the 
architecture  has  been  properly  defined,  other  processes  can  be  used  to  design  and 
implement  the  architecture. 
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EAP  must  co'ubine  the  definition  of  the  required  architecture  with  a  supporting 
plan  that  details  when  the  architecture  will  be  implemented.  Without  supporting 
implementation  plans,  the  EAP  team  should  keep  in  mind  that  the  end  product  must  go 
beyond  simple  definition  and  include  in  the  final  report  a  supporting  plan  for 
implementation. 

2.  The  Four  Layer  Model 

Spewak  defines  seven  components  of  EAP,  grouped  in  four  layers  to  successfully 
complete  the  plan,  see  Figure  1  [Ref.  1].  His  first  layer  is  Planning  Initiation,  which 
emphasizes  that  the  f  .AP  must  be  started  correctly,  with  the  right  tools,  right  people,  and 
the  right  expectation;,  .  The  second  layer  components  are  business  modeling  or  a  full 
analysis  and  undersU  r -ding  of  the  current  business  practices  and  the  information  that 
support  them. 

The  third  layer  is  the  heart  of  EAP.  The  components  of  this  layer  are  the 
definitions  of  the  data,  application  and  technology  architectures.  The  data  architecture  is 
defined  first,  then  the  application  architecture  is  defined  around  the  data,  then  the 
technology  architecture  is  developed  last  from  the  data  and  application  architecture. 
While  it  may  seem  quicker  or  easier  to  subdivide  these  architecture  developments  among 
different  teams,  or  to  develop  them  in  parallel,  Spewak  warns  against  it,  stating  “this 
approach  does  not  work  [Ref.  1].” 

The  fourth  layer  is  the  Implementation/Migration  plan  component.  This 
component  defines  the  sequence  and  schedule  for  implementation  and  the  migration  path. 
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as  well  as  some  cost  benefit  analysis.  This  is  the  plan  for  how  to  get  to  the  desired  end 
state  for  the  proposed  system. 


L  *yer3 


Layer  4j 


Implementation  /  Migration  Plans 


Figure  1.  The  Layers  of  EAP. 

B.  THE  COMPONENTS  OF  EAP 

As  described  above,  the  four  layers  of  the  methodology  are  broken  down  into 
seven  components.  This  section  is  intended  to  provide  an  overview  of  each  of  the 
components  of  the  methodology. 

1.  Planning  Initiation 

There  are  seven  major  steps  for  the  conduct  of  planning  under  the  EAP 
methodology.  This  section  will  briefly  introduce  those  steps,  formulated  by  Spewak  [Ref. 
1].  By  following  these  steps,  the  planner  can  begin  an  EAP  effort  that  is  properly  scoped, 
scheduled  adequately,  and  undertaken  with  the  appropriate  personnel. 
a.  Determine  Scope  and  Objectives 

The  first  step  in  defining  the  scope  is  to  actually  define  the  enterprise. 

Since  the  goal  of  EAP  is  to  allow  the  entire  organization  to  share  its  data,  the  planner 
must  ensure  that  aU  elements  of  the  enterprise  that  have  a  need  for  data  are  identified.  The 
scope  must  be  defined  to  include  all  elements  of  the  organization  that  wiU  need  to  share 
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data,  especially  across  organizational  boundaries.  The  planner  must  resist  the  temptation 
to  narrowly  define  the  scope  of  the  EAP  along  departmental  lines,  because  a  department 
will  almost  certainly  oeed  to  share  data  with  other  elements  of  the  enterprise.  An  EAP 
scope  that  is  too  narrow  will  result  in  a  product  that  is  inflexible,  difficult  to  integrate,  and 
which  falls  short  of  the  expectations  held  for  a  new  system. 

b.  Create  a  Vision 

This  step  is  a  difficult  one  for  even  the  best  information  systems  (IS) 
planners.  The  EAP  group  must  make  a  concerted  effort  to  understand  the  vision  and 
goals  of  the  business,  to  determine  IS  goals  that  will  support  the  goals  and  objectives  of 
the  core  business  functions.  Depending  on  the  role  of  IS  leadership,  they  might  have  been 
included  in  the  development  of  those  business  goals;  if  not,  the  IS  leadership  must  actively 
seek  the  stated  and  unstated  vision  and  goals  from  business  reports  and  documents. 

c.  Adapt  a  Methodology 

This  step  is  where  the  methodology  is  tailored  to  the  specific  needs  of  the 
organization.  Whatever  planning  structure  is  being  adapted  for  EAP  use,  it  must  remain 
flexible  and  adaptable,  use  automated  tools,  be  compatible  with  the  culture  and  politics  of 
the  organization,  update  the  organization  constantly,  and  result  in  a  long-range 
implementation  plan.  The  EAP  methodology  can  be  based  on  techniques  for  planning 
already  in  use  at  the  organization,  developed  from  scratch  internally,  or  developed  with 
the  aid  of  outside  speidalists.  As  long  as  it  can  be  adapted  to  the  peculiar  needs  of  the 
organization,  it  will  still  support  the  long  range  planning  goals. 
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d.  Arrange  for  Resources 

The  IS  leadership  must  prepare  for  the  EAP  effort  by  dedicating  the 
appropriate  computer  resources  and  other  product  resources  that  might  be  necessary  for 
the  EAP  team  to  successfully  complete  the  project.  This  might  include  data  access  and 
reports,  administrative  support,  programming  support  and  access  to  networks  and 
mainframes  used  by  the  organization. 

e.  A  ssemble  the  Planning  Team 

Spewak  identifies  this  step  as  the  most  critical.  The  team  leader  must 
possess  strong  leadership  skills  and  be  fluent  in  the  methodology  as  well  as  the  core 
functions  of  the  business.  The  team  itself  must  be  educated  in  EAP,  understand  the 
process,  and  be  committed  to  its  success.  They  must  have  credible  reputations  in  the 
organization,  and  must  be  willing  and  able  to  work  together  on  this  challenging  task. 

/.  Prepare  the  EAP  Workplan 

The  EAP  workplan  is  the  project  management  tool  for  the  EAP  effort.  It 
outlines  the  timeline  for  project  completion  with  milestones  to  keep  the  project  on  track, 
along  with  a  plan  for  all  team  activities.  The  time  schedule  is  critical  for  a  plan  of  this 
scope  because  if  the  effort  falls  behind  it  will  likely  fail.  Failure  to  produce  anticipated 
deliverables  may  diminish  credibility  with  management  and  endanger  the  project  as  well. 

g.  Obtain  Management  Approval 

Like  any  other  project  consuming  resources,  the  EAP  initial  plan  wiU  have 
to  be  presented  to  management  for  approval.  This  can  be  done  throughout  the  initiation 
phase,  or  once  the  plan  for  the  effort  is  completed.  The  group  leader  must  prepare 
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executive  level  briefs,  detail  the  plan,  listen  to  their  questions,  concerns  and  comments, 
and  be  prepared  to  address  those  issues.  After  approval  is  obtained,  the  decision  should 
be  widely  published  throughout  the  organization,  and  general  EAP  familiarization  training 
should  begin  for  the  entire  enterprise. 

2.  Business  Modeling 

Business  modeling  is  done  in  order  to  make  sure  the  business  is  properly  defined. 
The  model  is  the  mechanism  that  will  be  used  by  the  designers  and  users  to  ensure  that  all 
the  processes  of  the  o-ganization  are  being  considered  for  the  new  system.  Spewak 
defines  the  purpose  of  the  business  model  as  “to  provide  a  complete,  comprehensive, 
consistent  knowledge  base  that  can  be  used  to  define  the  architectures  and  implementation 
plans  [Ref.  1].”  He  divides  the  business  modeling  into  two  parts:  A  preliminary  business 
model,  and  a  complete  business  model. 

a.  Preliminary  Business  Model 

The  preliminary  business  model  is  composed  of  three  steps.  The  first  step 
is  to  document  the  organizational  structure  of  the  enterprise.  This  knowledge  of  the 
stmcture  will  help  the  EAP  team  decide  whom  to  interview,  and  will  also  help  in 
determining  data  sharing  requirements  and  application  sharing  requirements  later  in  the 
system  development.  The  information  may  be  available  immediately  to  the  team,  but  the 
team  should  validate  che  organizational  information  to  ensure  no  undocumented  changes 
have  occurred. 

This  documentation  will  identify  the  business  locations  of  the  organization, 
and  relate  them  to  the  organizational  units.  Business  locations  must  be  independently 
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evaluated  to  determine  if  they  are  an  attribute  of  organizational  units  or  a  separate  data 
structure  in  the  EAP  database.  This  step  must  also  document  the  business  goals  and 
objectives.  These  goals,  objectives  and  critical  success  factors  should  be  ranked  in  order 
of  importance.  Annual  budgets  and  organizational  plans  should  also  be  included  here  to 
contribute  to  sequencing  of  applications  in  accordance  with  organizational  importance. 

Finally  the  output  of  the  first  step  is  the  production  of  the  organizational 
units,  reporting  structure,  locations,  and  business  goals.  These  data  structures  and  reports 
must  be  reviewed  by  the  team  and  by  the  business  units  for  accuracy  in  documenting 
relationships  for  the  new  system  design. 

The  second  step  is  identification  and  definition  of  functions.  Identification 
of  the  functions  of  a  business  is  the  same  as  identifying  the  business.  Because  proper 
function  definition  is  so  critical  to  application  development,  this  step  is  probably  the  most 
important  in  the  entire  methodology.  The  quality  of  the  system  architecture  will  be  largely 
based  on  the  quality  of  the  business  model,  which  is  derived  from  the  definition  of  the 
business  functions. 

The  third  step  is  the  distribution  of  the  business  model.  This  includes  the 
production  of  the  output  of  the  business  modeling  process,  the  physical  distribution  of  that 
output,  and  the  feedback  from  the  organization  regarding  the  accuracy  of  the  model. 
Management  will  receive  an  updated  presentation  at  the  conclusion  of  this  project. 

b.  Complete  Business  Model 

The  chief  difference  between  the  complete  business  model  and  the 
preliminary  business  model  is  the  interview  process.  The  complete  business  model  will 
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include  the  result  of  interviews  conducted  after  the  organizational  analysis  has  been 
completed  to  decide  who  should  be  interviewed,  what  the  right  questions  are,  and  how  the 
information  obtained  from  the  interview  process  affects  the  business  model.  When  this 
analysis  is  complete,  so  is  the  business  model. 

3.  Current  Systems  and  Technology 

The  corps  of  the  current  systems  and  technology  component  is  the  Information 
Resource  Catalog  (IRC).  The  IRC  is  the  summary  listing  of  aU  the  components  of  the 
entire  information  system.  It  is  not  a  data  dictionary  or  an  equipment  inventory,  but  rather 
a  broad  scope  picture  of  the  major  elements  of  the  information  system. 

The  IRC  will  show  the  distribution  of  major  computer  resources  throughout  the 
enterprise,  and  defines  the  architecture  currently  in  place.  Collection  of  the  data  necessary 
to  complete  the  IRC  is  not  a  trivial  task.  It  requires  considerable  time  and  effort  and  must 
be  completed  before  the  architectural  phases  of  EAP  are  begun.  The  IRC  for  this  study  is 
included  as  Appendix  A. 

4.  Data  Architecture 

The  data  architecture  is  the  component  of  definition  for  the  elements  of  data 
needed  to  support  the  business  functions  identified  in  the  business  model.  Like  the  other 
components  of  EAP  the  definition  of  the  data  architecture  is  divided  into  steps.  The  first 
step  is  to  list  the  candidate  data  entities  for  definition.  This  is  usually  a  short  step,  and  can 
be  completed  in  a  fev'  brainstorming  sessions.  The  candidate  lists  should  include  some 
preliminary  attempts  at  definition,  and  indications  as  to  the  functions  and  use  of  the 
entities. 
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The  second  siep  is  to  define  the  data  entities,  their  attributes,  and  the  relationships 
between  the  entities.  There  are  several  methodologies  available  for  this  process.  Spewak 
recommends  the  Entity-Relationship  diagram  method.  Because  of  requirements  for 
standard  data  modeling  in  the  Department  of  Defense,  the  IDEE  IX  methodology  was  used 
to  model  the  data  architecture  for  MCI. 

The  third  step  is  to  relate  the  data  entities  to  the  business  model  developed  earlier. 
In  this  step  the  team  will  determine  which  data  entities  are  “created,  retrieved,  updated, 
and  deleted  by  business  functions”  [Ref.  1].  The  primary  tool  for  this  association  of 
entities  with  business  functions  is  the  CRUD  matrix.  By  the  use  of  this  matrix,  the  team 
can  determine  which  entities  are  created,  reference,  updated  or  deleted  by  business 
functions. 

The  fourth  step  is  distributing  the  data  architecture.  Like  the  business  model,  this 
involves  the  collection  of  all  the  information  generated  during  this  phase,  development  of 
the  data  model  itself,  the  preparation  for  presentation,  and  the  actual  presentation  of  the 
data  model  and  architecture  to  the  organization  and  to  management.  Feedback  from  the 
organization  and  from  management  should  then  be  considered  for  incorporation  into  the 
data  model. 

5.  Application  Architecture 

The  purpose  of  the  application  architecture  is  “to  define  the  major  kinds  of 
applications  needed  to  manage  the  data  and  support  the  business  functions  of  the 
enterprise”  [Ref.  1].  Tliis  component  is  not  a  design  for  the  system  or  a  detailed 
requirements  analysis  for  the  system.  Analogous  to  the  data  architecture,  the  first  step  of 
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the  application  architecture  is  to  identify  all  possible  applications  that  might  be  required  to 
manage  the  data  and  support  the  business  functions  of  the  organization.  Current 
applications  in  use  should  be  listed,  as  well  as  applications  with  potential  for  improving 
business  processes. 

The  second  step  is  to  define  aU  the  candidate  applications.  Application  definitions 
should  describe  what  an  application  does,  not  how  it  does  it.  The  application  descriptions 
should  not  be  linked  t.  )  a  particular  technology,  but  described  in  general,  non-technical 
terms. 

The  third  step  is  linking  the  applications  defined  in  step  two  to  the  functions  of  the 
business.  Matrices  are  used  to  display  the  correlation  of  the  applications  to  the  supported 
business  functions.  If  functions  are  discovered  to  have  no  application  support,  it  must  be 
determined  why  this  situation  exists. 

The  fourth  step  is  to  analyze  the  impact  of  the  developing  application  architecture 
on  the  current  applications.  The  application  architecture  can  be  compared  to  the  IRC  to 
determine  which  applications  are  completely  replaced  by  new  applications,  which  are 
partially  replaced,  anti  which  applications  will  be  retained,  possibly  with  some 
enhancement. 

The  final  step  is  the  presentation  and  feedback  step  for  the  organization.  The 
application  architecture  must  be  briefed  to  management  and  to  the  organization,  and 
feedback  of  the  architecture  is  considered  for  inclusion  to  the  final  product. 
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6.  Technology  Architecture 

Spewak  defines  the  purpose  of  the  technology  architecture  as  “defining  the  major 
kinds  of  technologies  needed  to  provide  an  environment  for  the  applications  that  are 
managing  data”  [Ref.  1],  The  definition  of  the  technology  architecture  is  one  of  the 
specific  goals  of  this  study,  and  is  discussed  in  Chapter  IV.  It  is  useful  to  introduce  it  here 
in  order  to  provide  the  reader  with  a  proper  context  for  understanding  the  specifics  of  the 
technology  architecture.  There  are  four  steps  that  make  up  Spewak’ s  technology 
architecture  framework. 

The  first  step  is  to  identify  technology  platforms  and  principles.  This  step 
establishes  the  guidelmes  for  the  entire  architecture  development.  The  principles  that  will 
govern  the  development  of  the  technology  architecture  must  be  based  on  trends  and 
directions  of  the  IS  industry.  A  wide  variety  of  literature  should  be  studied  to  ensure 
critical  industry  potentials  at  least  receive  due  consideration.  After  the  principles  are 
defined,  the  team  will  compile  a  list  of  the  potential  technology  platforms  for 
consideration. 

The  second  step  is  to  define  the  technology  platforms  and  distribution  of  those 
platforms.  With  the  principles  of  development  defined,  the  team  can  develop  their  strategy 
for  the  distribution  of  the  applications  and  data.  All  business  locations  affected  by  the 
architecture  will  be  identified  by  location  and  function.  The  physical  and  conceptual 
location  of  the  data  must  also  be  determined  in  the  distribution  plan.  Finally,  a  definition 
for  the  configuration  of  the  technology  platform  must  be  developed.  This  conceptual 
architecture  must  address  the  conceptual  workstation  (user  access),  the  conceptual 
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enterprise  network  (input/output,  storage  and  telecommunications)  and  the  business 
systems  architecture  (implementing  and  maintaining  applications  and  data  of  enterprise). 

The  third  step  is  to  relate  the  technology  platforms  to  the  applications  and  business 
functions  developed  in  the  earlier  components.  In  the  planning  guidelines  above,  the 
importance  of  linking  the  EAP  to  core  business  functions  was  discussed.  In  this  extension 
of  that  philosophy,  the  technology  platform  defined  must  be  related  to  the  business 
functions  that  will  use  them  and  to  the  applications  architecture  that  requires  that 
technology. 

The  fourth  step  in  Spewak’s  technology  architecture  is  to  distribute  the  technology 
architecture.  The  documents  defining  the  architecture  must  be  prepared  in  a  clear,  useful 
format,  then  presented  to  executive  management.  The  team  must  be  prepared  to  discuss 
the  potential  gains  and  risks  to  the  organization,  data  integrity  and  security  issues,  and 
implementation  concerns.  The  briefing  may  raise  new  issues  for  the  team,  and  those  issues 
must  be  considered  for  possible  revision  of  the  implementation  plan. 

7.  Implementation/Migration  Plans 

The  implementation  plan  is  last  of  the  components,  and  represents  the  bottom  layer 
of  the  EAP  methodology.  Without  a  plan  for  implementation,  the  entire  EAP  effort  will 
be  accepted  and  shelved  without  further  consideration.  This  plan  will  incorporate  several 
project  management  techniques,  and  is  a  long  term  plan  for  the  implementation  of  the  EAP 
findings. 

The  first  step  in  the  implementation  plan  is  a  sequencing  of  the  applications. 
Although  it  sounds  like  common  sense,  applications  that  create  data  should  be 
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implemented  before  applications  that  use  data.  The  sequence  of  implementation  should  be 
data  driven  and  adjusted  to  support  the  needs  of  the  business. 

The  second  step  is  to  estimate  the  effort  and  resources  required  for 
implementation,  and  to  produce  a  schedule.  This  step  includes  the  acquisition  estimates 
for  software  and  hardware,  the  estimation  of  available  resources  to  support  the  plan,  and 
the  use  of  project  management  techniques  to  produce  a  workable  schedule  for 
implementation. 

The  third  step  is  a  cost  and  benefit  analysis  of  the  plan.  Financial  concerns  will  be 
the  driving  force  behind  approval  for  implementation  of  the  plan.  Executive  decision 
makers  must  have  solid  data  on  economic  benefits,  rates  of  return  and  congruence  with 
long  term  business  goals  in  order  to  provide  the  financial  backing  for  an  effort  as  costly  as 
a  system  overhaul. 

The  fourth  step  is  to  determine  the  critical  success  factors  for  the  plan,  and  to 
prepare  recommendations  on  how  to  satisfy  them.  These  critical  success  factors  may 
include  such  things  as  new  organizations  in  the  enterprise,  new  development  methods,  . 
significant  budgetary  changes,  training  for  personnel,  and  reorganization  of  the  IS 
function.  All  of  these  factors  will  involve  change,  and  the  transition  management  must 
also  be  considered.  The  factors  influencing  transition  management  will  be  discussed  in 
detail  in  Chapter  VI. 

C.  ISSUES  REGARDING  EAP 

Spewak  addresses  several  additional  issues  for  consideration  by  planners 
considering  the  selection  of  a  planning  methodology.  He  contrasts  EAP  with  traditional 
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planning,  and  provides  an  overview  to  some  of  the  more  common  obstacles  faced  by 
planners  using  EAP. 

1.  EAP  Versus  Traditional  IS  Planning 

Spewak  summarizes  the  difference  between  EAP  and  traditional  IS  planning  as  a 
difference  of  the  driving  factors.  He  maintains  that  traditional  IS  planing  is  driven  by 
process  and  technology.  His  EAP  methodology  is  driven  by  data  and  business.  This 
fundamental  element  of  focus  is  what  makes  EAP  different. 

EAP  seeks  to  first  understand  the  business.  The  planning  team  conducts  the 
analysis  to  fuUy  under  ;tand  what  the  business  does  and  what  information  is  required  to  do 
those  things.  By  understanding  the  function  of  the  business  first,  the  architecture 
definition  is  driven  by  the  needs  of  the  business,  not  the  technology  the  business  is 
currently  using. 

The  step  associated  with  data  development  is  a  complete  reversal  from  the  norm. 
EAP  defines  the  data  before  the  applications.  The  component  of  data  architecture  defines 
all  the  data  needed  to  meet  the  business  needs  first,  then  defines  the  applications  required 
to  manage  that  data  in  the  application  architecture. 

Another  reversal  under  EAP  is  the  implementation  plan.  Traditional 
implementation  strategy  would  be  to  implement  at  the  highest  level  of  visibility.  EAP 
maintains  that  data  mast  be  created  before  it  can  be  used,  so  the  first  implementations 
should  be  at  the  creation  level,  which  is  usually  lower  visibility  than  the  management  level. 

The  last  major  difference  between  EAP  and  traditional  IS  planning  is  the  intended 
focus.  Traditional  IS  planning  has  focused  on  short  term  solutions  to  immediate  problems. 
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The  goal  of  EAP  is  a  long  term  solution  with  enough  flexibility  to  adapt  to  any  problem 
that  may  arise  from  the  business,  not  just  those  areas  with  high  profitability  or  immediate 
payback. 

2.  The  Zachman  Framework 

The  EAP  methodology  has  its  basis  in  the  Zachman  framework,  which  was  first 
published  in  1987  [Ref.  2  ].  This  was  the  first  paper  to  identify  a  “framework”  for 
analysis  of  information  systems.  Zachman  defined  six  levels  from  which  a  system  could  be 
viewed.  It  was  also  the  first  definition  of  the  three  layers  underlying  architectural 
planning:  data,  process,  and  network.  EAP  is  a  refinement  of  the  Zachman  framework, 
and  focuses  on  the  top  two  layers  -  the  ballpark  view  and  the  owner’s  view.  This  is  the 
basis  for  EAP  developing  the  definition,  but  not  the  design  of  information  systems. 

3.  Obstacles  to  EAP 

Spewak  identifies  several  common  obstacles  that  planners  should  be  prepared  to 
overcome  in  the  cour  se  of  EAP  efforts.  These  obstacles  range  in  levels  of  importance,  and 
some  of  the  more  crucial  obstacles  are  summarized  here. 

a.  Top  Management 

Support  of  top  management  is  the  key  to  any  successful  change  effort,  and 
EAP  is  no  exception.  The  key  decision  makers  must  be  educated  about  EAP,  and  realize 
that  the  EAP  effort  is  key  to  reaching  their  business  goals. 

b.  Resources 

Many  of  the  biggest  obstacles  to  effectively  implementing  an  EAP  involve 
the  lack  of  proper  financial  resources.  EAP  is  a  significant  undertaking  for  the 
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organization;  as  such  it  will  involve  the  dedication  of  personnel  and  financial  resources 
consummate  with  an  effort  of  its  scope.  The  proper  dedication  of  financial  resources  can 
be  an  effective  measure  of  the  true  support  of  top  management.  Failure  to  assign  the 
required  amount  of  qualified  personnel  to  an  EAP  effort  is  a  sure  sign  that  top 
management  is  not  fully  supporting  the  plan. 

The  priority  of  resource  allocation  is  also  another  indicator  of  potential 
success  for  EAP.  Th.-re  are  likely  numerous  IS  projects  waiting  in  a  backlog  in  any  IS 
organization.  If  EAP  is  to  be  effective,  it  must  be  conducted  before  things  that  have  been 
waiting  for  the  front  vf  the  queue.  The  impact  of  a  new  system  design  should  be  able  to 
incorporate  many  of  the  requirements  of  backlogged  requests  if  they  prove  to  be  tmly 
useful  in  support  of  the  business. 

The  other  major  resource  question  that  EAP  planners  will  face  is  that  of 
rates  of  return  on  investment.  The  proper  conduct  of  EAP  will  certainly  have  a  substantial 
up-front  cost.  There  will  not  be  an  immediate  return  on  EAP  efforts,  and  the  backers  of 
EAP  must  ensure  that  the  plan  is  given  support  to  be  able  to  get  to  the  design  phase  of  . 
development,  or  there  will  never  be  a  return  on  the  investment,  intrin.sic  or  otherwise.  The 
biggest  danger  of  this  type  of  failure  will  be  the  political  impact  it  will  have,  which  is 
discussed  below. 

c.  PiHitks 

The  first  political  problem  to  overcome  is  an  extension  of  the  argument 
above.  The  IS  department  of  any  organization  has  probably  been  responsible  for  projects 
that  were  substantially  late  and  over  budget.  If  the  IS  department  is  reflective  of  the  IS 
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field  as  a  whole,  perhaps  all  of  the  department  projects  have  been  substantially  late  and 
over  budget  This  legacy  wiU  be  the  &st  hurdle  in  selling  new  methodology  requiring  the 
dedication  of  financial  resources  and  top  people. 

Top  management  will  certainly  factor  the  past  performance  of  the  IS 
department  into  the  support  it  gives  the  EAP  effort  In  order  to  successfully  define  and 
design  the  organization,  the  plan  must  be  formulated  by  people  from  various  places  across 
the  enterprise.  Planners  must  ensure  the  people  involved  in  EAP  carry  strong  credibility  in 
the  organization,  so  these  people  must  be  educated  in  EAP  techniques  first. 

The  education  process  itself  is  wrought  with  political  issues  that  must  be 
addressed  by  the  EAP  proponents.  Technologically  oriented  people  are  even  more  likely 
to  see  EAP  as  a  “flavor-of-the- month”  and  dismiss  it  without  due  consideration.  IS 
leaders  must  find  the  proper  motivation  and  education  tools  to  ensure  buy  in  by  the  key 
people  in  the  IS  department  itself. 

There  are  many  political  facets  to  embarking  on  any  new  way  of  doing 
things.  The  last  area  to  discuss  here  is  again  internal  to  the  IS  department.  The 
responsibilities  for  many  EAP  functions  wiU  cross  normal  organizational  boundaries. 

There  will  be  a  tendency  to  try  the  “divide  and  conquer”  approach  to  this  effort.  The  EAP 
planner  must  resist  this,  because  shared  responsibility  for  EAP  will  significantly  reduce  its 
likeUhood  for  success.  The  shared  responsibility  wUl  blur  authority  Unes  and  increase  the 
political  role  of  the  human  dynamics.  Again,  detailed  discussion  of  the  political  factors 
affecting  transition  is  found  in  Chapter  VI. 
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d.  Corporate  Culture 

Since  FAP  will  require  organized  effort  across  the  enterprise,  there  will  be 
interaction  with  sections  outside  the  IS  department  that  might  not  normally  have  that  level 
of  interface  with  IS  planners.  This  integration  of  people  is  crucial  to  EAP’s  success.  IS 
planners  must  understand  the  core  business,  and  the  goals  for  successfully  reaching  those 
core  business  strategies.  Many  IS  departments  possess  an  institutional  arrogance 
regarding  their  role  in  the  business.  This  cannot  be  allowed  to  enter  into  the  EAP  process, 
as  it  will  poison  the  effort  from  the  beginning. 

e.  Inexperience  with  EAP 

Because  EAP  is  a  fairly  new  methodology,  it  is  likely  that  many  key  IS 
personnel  have  never  used  it  before.  It  is  critical  that  the  participants  understand  the 
methodology  before  attempting  to  initiate  the  planning,  or  the  credibility  of  the  entire 
effort  will  be  at  risk.  An  aggressive  education  program  must  be  conducted  to  minimize 
this  risk.  This  can  be  done  through  seminars,  outside  classes,  or  through  the  use  of 
training  consultants. 


24 


m.  OVERVIEW  OF  CURRENT  AND  TARGET  SYSTEMS 


This  chapter  i?  intended  to  provide  background  information  on  the  research 
sponsor  and  its  current  primary  information  system.  It  begins  with  a  brief  history  of  the 
Marine  Corps  Institute  (MCI),  and  the  development  of  their  automated  information 
system.  It  then  examines  in  detail  the  composition  of  the  existing  information  system  and 
provides  an  introduction  to  the  expectations  of  a  replacement  system. 

A.  HISTORY  OF  THE  MARINE  CORPS  INSTITUTE 

The  Marine  Corps  Institute  was  established  to  "develop,  publish,  distribute,  and 
administer  distance  training  and  education  materials  to  enhance,  support,  or  develop 
required  skills  and  knowledge  of  Marines  and  to  satisfy  other  training  and  education 
requirements  as  identified  by  the  Commanding  General,  MCCDC."  To  accomplish  its 
mission,  MCI  is  organized  into  seven  functional  departments:  education  and  operations, 
student  services,  information  management  systems,  occupation  specialty,  professional 
military  education,  production,  and  logistics. 

The  mission  of  the  Student  Services  Department  (SSD)  is  to  support  the 
enrollment,  grading  and  management  of  the  Marine  Corps  distance  education  and  training 
programs.  It  is  the  focal  point  of  most  past  complaints  from  students,  and  has  received  the 
majority  of  attention  as  the  logical  place  to  begin  to  seek  improvement  in  customer 
support.  In  support  of  its  mission,  SSD  employs  an  automated  information  system  (AIS) 
to  automate  the  actions  required  to  administratively  support  a  student  in  one  of  the  MCI 
correspondence  programs,  maintain  student  records,  and  produce  necessary  management 
reports. 
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B.  HISTORY  OF  THE  MARINE  CORPS  INSTITUTE  AUTOMATED 

INFORMATION  SYSTEM 

The  automated  system,  known  as  the  Marine  Corps  Institute  Automated 
Information  System  (MCIAIS)  is  a  legacy  system  developed  in  the  late  1970's.  It  runs  on  a 
Hewlett-Packard  3000/957  mini  computer  mnning  the  Hewlett-Packard  MPE/iX 
operating  system.  MCLAIS  is  written  in  a  Hewlett-Packard  proprietary  language  called 
"Transact"  and  accesses  a  Turboimage  hierarchical  database. 

MCIAIS  has  been  modified  without  documentation  for  many  years.  As  a  result  of 
these  modifications,  it  no  longer  efficiently  supports  business  requirements,  and  does  not 
have  the  flexibility  to  support  emerging  business  requirements  generated  by  new 
technology  development.  As  is  typical  of  many  legacy  systems,  MCIAIS  suffers  from 
many  shortcomings: 

•  It  has  over  1 10  "spaghetti  coded"  programs  that  are  difficult  to  maintain, 
modify,  and  upgrade. 

•  It  does  not  have  underlying  data  or  process  models 

•  Programs  have  poor  functionality:  Poor  checks  and  balances;  no  statistical 
analysis  capability;  and  limited  "ad  hoc"  query  capability. 

•  It  utilizes  a  "closed"  non-relational  database. 

•  It  does  not  support  Graphical  User  Interfaces  (GUI). 

In  response  to  these  shortcomings,  and  in  order  to  improve  flexibility  for  better 
student  support,  MCI  initiated  a  project  to  redesign  and  replace  MCIAIS  using  an  open 
hardware  and  software  architecture.  In  addition,  MCI  is  also  reviewing  and  redesigning 
business  processes  to  better  support  its  mission  and  current  advances  in  training  and 
education.  This  effort  is  a  recognition  of  the  fact  that  the  role  of  MCI  in  the  Marine  Corps 
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has  changed  significantly  in  the  last  year.  Because  of  directives  from  the  Commandant  of 
the  Marine  Corps,  coorses  developed  and  administered  by  MCI  have  been  directly  linked 
to  individual  Marines’  careers  as  a  prerequisite  to  promotion.  The  impact  of  this  linkage 
has  been  to  significantly  raise  the  visibility  of  the  student  support  provided  by  MCI.  The 
intent  of  this  research  is  to  improve  that  support  through  the  definition  of  a  new 
information  system. 

As  discussed  in  Chapter  II,  the  technology  architecture  development  methodology 
was  applied  to  this  requirement  to  develop  an  architecture  definition  that  would  satisfy  the 
business  requirements  of  MCI.  While  the  specifics  of  developing  a  technology 
architecture  will  be  discussed  in  Chapter  IV,  the  first  step  of  the  methodology  requires  an 
examination  of  the  system  currently  in  place,  and  is  conducted  in  the  remainder  of  this 
chapter. 

C.  CURRENT  SYSTEM 

In  order  to  properly  plan  the  migration  from  the  legacy  system  to  the  target 
system,  the  current  system  must  be  described  in  detail,  to  determine  which,  if  any,  part  of 
the  current  system  will  be  useful  in  the  target  system.  The  current  system  was  inventoried 
according  to  the  Information  Resource  Catalog  technique  (see  Appendix  A)  as  detailed  in 
Spewak’sbook  [Ref.  1]. 

1.  Current  Hardware  Environment 

The  current  hardware  environment  is  a  composition  of  computers  of  various  types 
and  their  supporting  peripherals. 
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a.  Computers 

The  center  of  MCIAIS  is  the  Hewlett-Packard  3000/957  SX 
minicomputer  with  160  MB  of  memory.  It  has  been  recently  upgraded,  and  adequately 
supports  the  information  system  in  its  current  form.  There  are  currently  three 
microcomputer  servers  located  at  MCI. 

•  Two  Dell  486-66  MHz  machines  with  32  MB  memory  and  7.5  GB  disk  arrays 

•  Dell  Pentium-60  MHz  with  64  MB  memory  and  a  8  GB  disk  array 

•  Automated  Voice  Response  (AVR)  System,  Pentium  with  32MB  of  memory 
and  1.2  GB  storage  for  automated  dialup  customer  support. 

The  other  microcomputers  in  use  at  MCI  are  serving  as  either  networked 
or  stand  alone  personal  computers.  At  the  beginning  of  his  study,  there  was  a  wide  range 
of  microcomputers  with  different  capabilities.  Many  of  the  customer  support  personnel 
were  using  386  based  machines.  Part  of  the  effort  to  improve  customer  support  focused 
on  upgrading  the  older  microcomputers  to  state-of-the-art  computers.  Currently  aU  PC’s 
at  MCI  are  being  replaced,  or  have  already  been  replaced  with  Pentium  90  MHz 
microcomputers  with  at  least  16MB  of  memory,  some  ranging  up  to  40MB  of  memory. 
All  of  the  Pentium  microcomputers  have  a  minimum  of  1.2  GB  of  storage. 

b.  Peripherals 

The  peripherals  found  at  MCI  in  support  of  the  various  computing 
requirements  include: 

•  One  kodak  digital  camera 

•  Two  flatbed  scanners 

•  Thirty  five  laserjet  printers 


28 


•  One  HP  1 600  line  printer 

•  One  Xerox  4850  laser  printer 

•  One  compact  disk  storage  array  with  six  CD  drives 

•  One  rewritable  CD  drive  for  information  storage 

•  One  HP  6250  Streaming  Tape  drive 

•  One  NCS  model  OP7-35  form  input  scanner  for  test  grading 

•  One  HP  6000  SCSI  Storage  system  consisting  of  four  2GB  disk  drives 

•  Two  2GB  SE  SCSI  disk  drives 

•  One  2GB  DDS  DAT  drive. 

2.  Current  Software  Environment 

The  current  software  environment  covers  a  wide  range  of  system  and  application 
software  to  meet  the  requirements  of  the  users  at  MCI.  There  are  several  operating 
systems,  at  least  two  network  operating  systems  and  a  host  of  applications  that  must  be 
supported. 

a.  Operating  System 

The  operating  system  running  the  HP  minicomputer  is  a  HP  proprietary 
operating  system  known  as  MPE/iX  version  5.5.  It  is  a  POSIX  compliant  operating 
system,  familiar  to  the  senior  information  systems  (IS)  staff,  but  novel  to  the  junior 
members  of  the  IS  Staff.  It  is  not  accepted  as  a  standard  operating  system  in  the  Marine 
Corps,  but  has  been  widely  used  for  financial  applications  in  other  Department  of  the  Navy 
sites.  It  is  flexible  and  open  enough  to  support  current  system  requirements,  and  even 
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near  term  future  requirements,  but  staff  training  in  MPE/iX  is  a  critical  concern  for  future 
support. 

The  majority  of  the  microcomputers  at  MCI  are  running  Windows  95,  but 
some  of  the  personnel  at  MCI  have  yet  to  upgrade  Windows  3.1 1  to  32  bit  systems.  AH 
of  the  PCs  in  use  at  MCI  are  operating  on  a  DOS  6.22  base.  There  is  currently  one 
microcomputer  running  Windows  NT,  version  4.0.  This  computer  is  designated  as  the 
Web  server  for  MCI. 

h.  Network  Operating  System 

The  network  operating  system  (NOS)  currently  used  at  MCI  is  primarily 
Banyan  Vines  versio>*  6.3(0).  Banyan  Vines  is  currently  the  standard  NOS  for  the  Marine 
Corps.  Banyan  Vines  is  robust  and  flexible  enough  to  support  all  the  current  needs  of 
MCI,  and  personnel  are  well  trained  in  its  use. 

c.  Application  Software 

As  typical  of  any  organization,  there  are  a  wide  variety  of  applications 
supported  by  the  IS  staff.  Many  of  the  applications  support  other  business  functions  of 
MCI  in  addition  to  SSD.  The  categories  of  applications  found  at  MCI  are  application 
suites,  graphics,  message  preparation,  project  management,  utility,  e-mail  and  some 
specialty  applications.  A  detailed  listing  of  these  applications  can  be  found  in  the 
Information  Resource  Catalog  located  in  Appendix  A. 

3.  Current  Networking  Environment 

The  networking  environment  at  MCI  is  the  least  flexible  and  most  saturated 
portion  of  the  information  system.  The  IS  staff  has  done  a  credible  job  supporting 


30 


requirements  with  available  resources,  but  the  current  network  environment  no  longer 
supports  the  requirements  of  MCI,  and  is  not  likely  to  support  the  future  requirements  of 
an  expanded  information  system  and  increased  dependence  on  the  information  provided  by 
that  system.  While  the  Local  Area  Network  (LAN)  is  adequate  for  today’s  needs,  the 
Wide  Area  Network  (WAN)  or  outside  connectivity  is  seriously  inadequate  to  meet  even 
current  requirements. 

a.  Da  'a  Links 

The  current  primary  data  connectivity  outside  of  MCI  is  a  56  kbps 
(thousand  bits  per  second)  line  to  Headquarters,  U.S.  Marine  Corps  (HQMC).  This 
bandwidth  is  totally  inadequate,  and  is  planned  for  upgrade  to  T1  immediately.  This  T1 
will  be  attaehed  to  a  Cisco  4500M  router.  In  addition  to  this  primary  data  link,  MCI  has 
he  following  data  equipment: 

•  Five  dial-up  phone  hnks,  operating  at  28.8  kbps 

•  Two  Cabletron  MMAC-8  Hubs  with  one  management  module  (w/SNMP)  per 
hub 

•  Four  24-port  lObaseT  ethernet  modules  for  user  ports 

•  One  FDDl  module  per  hub 

To  increase  data  throughput  for  MCI,  a  24-port  100  mbps  (million  bits  per  second) 
switched  fast  ethernet  hub  is  planned  for  application  server  traffic  and  high-speed 
connections  for  data  processing  personnel. 

Data  connectivity  between  MCI  and  the  headquarters  at  Marine  Barracks, 
8th  and  I  streets  is  provided  by  an  AirLan/Bridge,  with  long  range  1  Idb  directional 
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antenna,  providing  a  2  mbs  data  transfer  rate  over  spread-spectrum  transmission  in  the  900 
MHz  frequency  range. 

b.  Internet 

All  connectivity  to  the  Internet  is  provided  via  the  56  kbps  link  to  HQMC. 
With  the  role  of  the  Internet  expanding  every  day,  the  planned  T1  upgrade  to  this  link  will 
prove  insufficient  for  future  growth  as  weU.  MCI  has  added  an  informational  web  site 
which  is  likely  to  increase  the  bandwidth  demand  on  this  T1  data  link.  While  the  role  of 
the  Internet  in  curren;  business  practice  is  not  included  in  MCI’s  short  term  plans,  the 
utility  of  an  expanded  Internet  presence  will  certainly  have  to  be  a  central  element  of  focus 
for  information  system  planning. 

D.  TARGET  CLIENT/SERVER  ENVIRONMENT 

The  most  radical  change  in  moving  to  a  new  information  system  for  MQ  will  be 
the  change  from  a  mainframe/minicomputer  or  host  centric  environment,  to  a  client/server 
environment  emphasizing  distributed  computing.  The  level  of  distribution  is  determined 
by  the  planners  based  on  the  logical  location  of  the  required  processing.  The  target 
environment  must  pnwide  regulated  access  to  shared  resources  by  many  clients  at  one 
time,  with  the  information  processing  required  by  that  access  located  where  it  best 
facilitates  communication.  The  specifics  of  the  target  system  requirements  will  be 
discussed  in  Chapter  iV,  but  a  general  introduction  is  provided  here  to  contrast  the  current 
MCIAIS. 
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1.  Target  Hardware  Environment 

The  target  hardware  environment  is  one  that  provides  state  of  the  art  processing 
power  to  both  the  client  and  server  side  of  the  system.  It  is  designed  for  ease  of 
installation  of  periphe  al  equipment,  low  mean  time  between  failure  rates,  ease  of 
maintenance,  high  scalability,  disk  mirroring  for  data  redundancy,  high  security,  and  ease 
of  operation  for  the  IS  personnel. 

The  target  hardware  can  be  minicomputer  or  a  microcomputer  based,  as  long  as  it 
supports  open  architecture  and  the  need  for  increased  flexibility  and  scalability.  Specific 
alternatives  for  both  types  of  target  systems  are  discussed  in  detail  in  Chapter  IV. 

2.  Target  Software  Environment 

Open  systems  are  the  prevailing  industry  trend  for  operating  systems.  Any 
operating  system  chosen  for  the  target  system  must  conform  to  aU  open  standards,  and 
support  the  flexible  addition  of  new  equipment,  ease  of  operability  for  IS  personnel,  high 
security,  support  for  multiple  protocols,  high  integrity,  and  reliable  support.  Open 
standards  insure  the  ability  to  mix  and  match  various  protocols  that  might  need  to  be 
integrated  to  support  emerging  business  requirements. 

Relational  databases  are  the  most  prevalent  database  applications  in  industry  today. 
The  application  software  chosen  for  the  target  environment  must  support  relational 
database  structure  to  eliminate  the  limitations  of  the  current  hierarchical  database. 

3.  Target  Networking  Environment 

Like  the  targe-'  hardware  and  software  environments,  the  target  networking 
environment  must  eniphasize  flexibility.  The  key  to  flexibility  in  networking  is  bandwidth 
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planning.  MCI  needs  to  begin  planning  for  adopting  an  Internet  strategy  in  the  future 
business  plan.  Appropriation  planning  to  obtain  the  required  bandwidth  to  support  this 
plan  should  begin  now.  The  target  networking  environment  should  be  planned  around 
standard  equipment  for  Marine  Corps  infrastructures  to  reduce  training  requirements  for 
new  personnel.  Existing  plans  to  upgrade  to  100  mbps  service  to  networked  users  is  a 
step  in  the  right  direc-ion,  but  this  type  of  improvement  must  not  be  viewed  as  a  final  step, 
rather  as  an  intermediate  step  in  support  of  the  ever  increasing  requirements  of  complex 
information  system  scpport. 
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IV.  TECHNOLOGY  ARCHITECTURE  DEFINITION  FOR  MCI 

This  chapter  further  defines  the  technology  architecture  for  MCI  that  was  briefly 
described  in  Chapter  III.  It  describes  the  principles  of  development,  defines  three 
technology  platforms  for  consideration,  associates  the  technology  platforms  with  business 
functions  and  applications,  and  discusses  the  distribution  of  those  applications  and  the 
supporting  data. 

A.  ENTERPRISE  TECHNOLOGY  ARCHITECTURE 

As  Chapter  11  clearly  pointed  out,  one  of  the  critical  tenets  of  EAP  is  that  planning 
is  conducted  at  the  enterprise  level.  The  scope  of  what  could  be  considered  an 
“enterprise”  for  this  project  was  unclear  as  the  following  section  illustrates. 

1.  Scope  of  the  Enterprise  Architecture 

By  industry  standards,  MCI  is  not  considered  a  large  enterprise.  In  fact,  some 
definitions  would  not  classify  MCI  as  an  enterprise  at  aU.  A  case  could  be  made  that  MCI 
is  a  single  business  unit,  and  the  information  system  under  development  is  to  support  the 
core  business  functions  of  that  business  unit.  The  business  functions  identified,  however, 
are  central  to  the  mission  of  MCI  and  serve  as  the  core  business  functions  of  the 
enterprise.  Since  the  scope  of  the  redesign  effort  for  this  study  was  narrowly  defined 
around  SSD,  it  was  clear  that  a  technology  architecture  could  not  be  readily  developed  by 
the  Naval  Postgraduate  School  (NPS)  project  team  for  the  entire  enterprise.  The 
development  effort  focused  on  the  business  functions  of  SSD,  which  represent  the  large 
majority  of  the  core  processes  of  MCI.  Even  though  the  scope  of  the  study  was 
intentionally  set  at  the  business  unit,  proper  use  of  the  EAP  methodology  required  that  the 
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enterprise  be  given  consideration  in  the  development  of  the  technology  architecture.  This 
meant  that  other  processes  outside  of  SSD  that  were  identified  by  MCI  personnel  and 
team  analysts  as  critical  to  the  business  processes  of  MCI  must  be  added  to  the  technology 
architecture  under  development. 

The  artificial  scoping  of  the  project  created  a  difficult  situation  for  the  project 
team.  Any  recommendations  made  to  MCI  for  potential  technology  platforms  must  have 
the  potential  and  capability  to  support  the  requirements  of  the  entire  enterprise.  The 
project  team  elected  to  add  the  key  elements  from  the  external  business  processes  to 
increase  the  viability  of  the  project. 

While  technology  architecture  recommendations  for  SSD  are  based  on  detailed 
analysis  for  the  business  processes  and  data  requirements  of  SSD,  the  hardware  and 
software  chosen  as  the  technology  platform  must  be  robust  enough  to  support  the 
immediate  and  eventual  needs  of  the  enterprise. 

The  primary  business  unit  external  to  SSD  with  significant  impact  on  the  system 
was  the  Logistics  Department.  High  level  business  functions  and  data  entities  for  that 
department  were  modeled  and  data  interfaces  with  SSD  were  identified.  This  information 
was  considered  in  the  development  of  the  technology  platforms  applied  in  this  chapter. 

2.  Principles  of  Development 

The  purpose  of  establishing  principles  of  development  for  the  enterprise  is  “to 
identify  underlying  principles  for  technology  platforms  and  the  potential  platforms  needed 
to  support  an  enterprise  wide,  shared  data  environment”  [Ref.  1].  This  identification  is  the 
first  step  of  the  EAP  technology  architecture  methodology.  The  following  principles 
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apply  to  the  formulation  of  an  enterprise  technology  architecture  for  the  Marine  Corps 
Institute  project  [Ref.  1]: 

•  Client/server  technology  will  be  used  for  applications  and  database 
implementation. 

•  A  common  graphical  user  interface  will  be  used  by  all  applications. 

•  Data  storage  will  use  relational  technology,  and  data  access  will  employ  SQL. 

•  Design  wi^l  apply  open  system  concepts,  meaning  operating  systems  should  be: 
Portable:  tun  across  multiple  vendor  platforms; 

Scalable:  run  across  a  wide  power  range  from  small  to  large  computers; 
Interoperable:  run  in  a  heterogeneous  environment;  and 
Compatible:  preserve  the  investment  in  existing  software  and  enable 
technology  advances  to  be  integrated  with  other  components. 

•  System  development  methodology  should  employ  object  oriented 
techniques,  information  engineering  methods,  and  be  supported  by 
CASE  and  repository  tools  from  requirements  analysis  through  code 
generation. 

•  Data  should  be  captured  once  at  its  soiurce. 

•  Data  should  be  administered  centrally  and  maintained  for  shared  access. 

•  Information  that  is  stored  online  will  be  continuously  available. 

•  Distributed  data  and  application  systems  will  be  implement  where 
possible. 

•  The  security  of  data,  software,  and  hardware  assets  at  all  levels  of  the 
technology  architecture  will  be  maintained  with  security  being  as 
transparent  as  possible. 

•  Recoverability  will  be  emphasized  to  ensure  to  protect  the  continuation  of 
business  by  having: 

adequate  and  appropriate  backups  of  all  data; 

software  with  built-in  error  checking  and  recovery  capabilities;  and 

integration  and  compatibility  of  hardware  with  redundancies  for  critical 

operations 
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•  Established  Marine  Corps  standards  for  software  will  be  followed. 

•  Data  storage  requirements  must  be  compatible  with  World  Wide  Web  access 
requirements 

B.  BUSINESS  UNIT  LEVEL  TECHNOLOGY  ARCHITECTURE 

As  indicated,  only  a  minimal  analysis  was  conducted  for  the  development  of  a 
technology  architecture  for  the  entire  MCI  enterprise.  The  focus  on  the  development  of 
the  technology  archit  ecture  was  for  the  business  unit  level,  the  Student  Services 
Department. 

1.  Hardware  Platforms 

Three  target  hardware  platforms  were  considered  as  suitable  replacement 
alternatives  for  the  existing  system.  All  three  hardware  alternatives  comply  to  a  varying 
degree  with  the  principles  established  in  the  previous  section.  Two  of  the  hardware 
alternatives  are  minicomputer  based  while  the  third  is  microcomputer  based.  The 
requirements  and  considerations  for  the  hardware  were  discussed  in  Chapter  HI. 

2.  Operating  Systems 

Each  of  the  three  hardware  alternatives  has  its  own  operating  system  option. 
Three  operating  systems  were  considered.  All  three  are  considered  to  be  relatively  open 
systems.  All  three  operating  systems  are  flexible  enough  to  adapt  to  the  changing 
conditions  expected  in  the  near  future,  and  aU  three  operating  systems  run  the  selected 
database  management  software. 

3.  Application  Development  Environment 

The  primary  application  development  tool  recommended  by  the  project  team  is 
Oracle®  Developer  2000.  This  application  development  tool  was  chosen  for  its  robust, 
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industrial-strength  development  capability  and  its  strong  security  features.  Used  in  tandem 
with  Oracle®  Designer  2000,  this  suite  is  considered  one  of  the  leading  application 
development  tools  in  the  industry.  In  addition  to  its  favorable  reputation,  the  Oracle® 
development  suite  is  seamlessly  integratable  with  Oracle®  Server,  the  chosen  database 
management  system. 

Other  application  development  tools  were  considered  and  dismissed.  Borland’s 
Delphi,  Cognos’  Power  Builder,  and  Microsoft’s  Visual  Basic  were  all  considered  for 
application  development,  but  none  could  match  the  advantages  and  fit  of  Oracle® 
Developer  2000.  The  project  team,  however,  did  not  use  the  Designer  2000  development 
tool,  because  it  does  not  support  the  IDEF  modeling  techniques,  identified  by  the 
Department  of  Defense  as  the  standard  for  data  modeling.  Consequently  Erww®  and  its 
sister  tool  BPwm®  were  chosen. 

4.  Database  Management  System 

The  database  management  system  (DBMS)  selected  for  the  technology  platform  is 
Oracle®  Server.  Other  DBMS  were  considered  during  research,  but  Oracle®  was  selected 
for  two  main  considerations.  It  has  been  named  as  the  standard  large  scale  DBMS  for  the 
United  States  Marine  Corps  [Ref.  3],  and  training  at  no  cost  to  MCI  was  available  locally 
for  the  project  team  in  Oracle®  Server  and  Oracle®  Development  tools.  In  addition,  NPS 
was  installing  the  Oracle®  Server  products,  and  local  expertise  was  available  at  the  school. 

C.  DEFINITION  AND  EVALUATION  OF  PROPOSED  BUSINESS  UNIT 

LEVEL  TEC:HN0L0GY  ARCHITECTURES 

This  step  is  ir  tended  to  look  at  the  conceptual  architecture  at  three  levels:  the 

conceptual  workstation,  the  conceptual  enterprise  network,  and  the  business  systems 
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ai'chitecture.  The  conceptual  enterprise  network  is  being  considered  because  the 
technology  architectm  e  for  the  business  unit  level  must  also  be  capable  of  supporting 
enterprise  requirements  for  MCI.  This  architectural  definition  is  further  subdivided  into 
three  options  for  consideration  by  MCI.  Each  of  the  three  options  is  evaluated  under  the 
guidelines  established  for  this  step.  In  addition  to  EAP  considerations,  details  affecting 
system  migration  are  included  for  consideration  with  each  option.  Other  details,  such  as 
communication  specifics  for  the  final  system  design,  will  necessarily  be  incorporated  as  the 
final  design  is  developed  by  the  implementation  team.  The  intent  here  is  to  show  a  broad 
conceptual  design  without  committing  to  exact  specifications.  In  developing  these 
options,  a  seven  year  system  life  was  assumed  and,  in  compliance  with  a  MCI  request, 
only  initial  costs  were  considered. 

1.  Option  One  -  HP  Minicomputer  Server  Running  MPE/iX 

a.  HardwarelSoftware  Considerations 

This  option  keeps  the  existing  HP  3000  model  957SX  minicomputer 
server,  while  replacing  the  current  database  system  and  its  applications  with  a  relational 
database  system  and  associated  applications.  The  current  minicomputer  will  require  some 
upgrade/replacement  of  hardware  and  software  to  meet  the  expected  growth  requirements 
of  MCI.  The  957SX  can  be  upgraded  in  incremental  steps  up  to  a  model  987/200  which  is 
six  times  more  powerful  than  the  existing  minicomputer.  There  are  four  levels  of  upgrade 
available  to  MCI  at  increasing  increments  of  cost.  MCI  has  two  microcomputer  purchase 
initiatives  currently  v-nderway  to  replace  outdated  computers.  These  efforts  will  satisfy 
client  workstation  requirements  for  SSD.  Upgrades  to  these  client  workstations  can  be 
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liiTiited  in  scope  to  minor  hardware  upgrades  if  continued  migration  to  a  different  platform 
is  considered.  This  option  is  depicted  in  Figure  2. 
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Figure  2.  Option  One  Technology  Architecture. 


b.  Migration  Issues 


The  ability  to  use  the  existing  hardware  and  operating  system  (MPE/iX) 
will  enable  an  incremental  transition  for  the  MIS  personnel.  By  adding  the  relational 
database  to  existing  hardware  and  operating  system,  the  MIS  personnel  can  focus  then- 
training  strategies  on  the  transition  to  a  new  database  management  system  without 
simultaneously  having  to  learn  new  hardware  and  operating  systems. 

A  main  input  data  (MCTFS)  for  the  new  database  is  currently  available  on 
the  HP  3000.  This  data  can  be  imported  easily  into  the  new  database  without  the  purchase 


of  any  additional  equipment.  By  implementing  this  option,  the  new  database  will  be 
installed  on  the  same  server  as  the  existing  database,  thus  simplifying  migration. 

c.  A  dvantages  of  Option  One: 

•  Current  personnel  trained  on  HP  3000  hardware  and  MPE/iX  operating 
system 

•  Support  system  already  in  place  for  HP  products 

•  Potentially  simplified  migration 

•  Gateway  product  immediately  available 

d.  D:  ladvantages  of  Option  One: 

•  MPE/DC  is  not  DOD  or  USMC  standard 

•  MPE/iX  is  not  a  truly  open  system 

•  High  yearly  maintenance  costs 

•  High  upgrade  costs  to  maximum  capability 

•  Not  responsive  to  future  changes 

2.  Option  Two  -  HP  Minicomputer  Server  Running  UNIX  (HP/UX) 
a.  Hardware/Software  Considerations 

Option  two  requires  a  change  to  both  the  central  hardware  and  operating 

system.  The  HP  30(K)  would  be  replaced  with  an  HP  9000  model  969/200  mnning 

HP/UX,  which  is  the  HP  version  of  the  UNIX  operating  system.  The  HP  9000  969/200  is 

the  next  generation  of  HP  minicomputer  and  is,  according  to  benchmark  tests,  seven  times 

more  powerful  than  the  current  system. 

Option  two  establishes  a  relational  database  on  the  new  minicomputer, 

replacing  the  current  database  system  and  related  applications.  This  database  server  will  be 
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capable  of  meeting  the  business  needs  of  SSD  for  the  required  growth  cycle  (7  years).  The 
two  microcomputer  purchase  initiatives  currently  underway  will  satisfy  client  workstation 


requirements.  This  option  is  depicted  in  Figure  3. 


b.  Migration  Issues 


This  option  represents  a  greater  level  of  change  than  option  one,  but  less 
drastic  change  than  option  three.  It  will  require  extensive  training  of  MIS  personnel  in 
UNIX,  and  this  training  requirement  alone  increases  the  complexity  of  the  transition. 
Entry-level  MIS  personnel  at  MCI  have  had  some  UNIX  exposure,  but  current  training 
levels  are  inadequate  for  the  requirements  of  this  transition.  UNIX  is  an  open  system, 
widely  used  in  industry  and  DOD.  Oracle®  support  and  experience  with  UNIX  platforms 
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is  the  most  developed.  The  likelihood  of  simplified  interface  with  developing  technologies 
for  future  applications  and  equipment  is  improved  with  the  UNIX  O/S.  HP  personnel  will 
be  available  for  hardware  migration  assistance  to  facilitate  the  cutover  from  one 
technology  platform  to  the  other.  This  solution  is  evaluated  as  having  greater  risk  of 
failure  than  option  one. 

c.  Advantages  of  Option  Two: 

•  More  open  and  more  standard  operating  system 

•  UNIX  O/S  is  preferred  platform  of  Oracle® 

•  UNIX  O/S  provides  better  World  Wide  Web  interface  and  design 

•  UNIX  O/S  simplifies  external  services  (print  gateway) 

•  Scalability 

d.  Disadvantages  of  Option  Two: 

•  Significant  learning  curve  for  senior  MIS  personnel 

•  More  complex  migration  due  to  the  requirement  of  new  hardware  and 
software 

•  UNIX  security  weaknesses 

•  High  yearly  maintenance  costs 

•  High  investment  may  stymie  future  migration  efforts 

3.  Option  Three  -  Intel  Based  Server  Running  NT 

a.  Hardware/Software  Considerations 

This  option  represents  a  core  shift  in  computing  philosophy  for  MCI.  It 
replaces  the  current  minicomputer  with  a  state-of-the-art  multi-processor  microcomputer. 
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It  will  take  advantage  of  intensive  industry  development  by  Oracle®  ,  and  represents  a 
significantly  smaller  capital  investment  on  the  part  of  MCI. 

This  option  requires  the  replacemenl/upgrade  of  existing  workstations  with 
new  equipment  (increased  memory),  and  an  entire  0/S  migration  from  existing  software. 

It  would  standardize  the  0/S  for  the  database  server,  LAN  servers,  and  all  workstations  to 
Windows  NT.  The  client  microcomputers  for  SSD  (and  any  other  users)  must  be  32  bit 
systems,  Pentium  processors,  with  a  minimum  of  16  MB  memory  and  1  GB  storage.  They 
must  be  configured  fo  network  access  and  provide  access  to  electronic  mail,  business 
suite  applications,  a  relational  database,  message  system  software,  World  Wide  Web 
access,  and  customer  service/help  desk  applications.  This  option  is  depicted  in  Figure  4. 


Figure  4.  Option  Three  Technology  Architecture. 
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b.  Migration  Issues 


This  option  represents  the  most  complex  change  and  can  therefore  be  the 
most  problematic.  It  will  require  MIS  personnel  to  learn  a  new  0/S,  new  hardware,  new 
applications,  and  a  new  DBMS  simultaneously.  It  will  be  the  most  difficult  migration 
implementation.  It  will  require  a  sophisticated  gateway  for  transition  from  MPE/iX  Turbo 
Image  to  a  Windows  NT  based  version  of  Oracle®  7.3. 

This  option  does  embrace  emerging  technology  and  will  place  MCI  in  the 
front  of  the  mainstream  of  technological  implementation.  There  is  significant  likelihood 
that  the  USMC  is  transitioning  to  NT  as  a  server  O/S,  and  this  would  position  MCI  to 
have  an  O/S  that  was  standard  compliant  and  enterprise  wide  (mail  server,  web  server,  file 
server,  database  server  all  on  the  same  O/S).  This  would  simplify  middleware  issues  for 
the  system. 

c.  Advantages  of  Option  Three: 

•  Oracle®  corporate  interest  in  NT  developments 

•  Position  for  standardized  operating  systems 

•  Current  direction  of  industry 

•  Newest  technology 

•  Hardware  costs  are  comparatively  low 

•  The  most  responsive  option  to  future  changes 

d.  Disadvantages  of  Option  Three: 

•  Very  steep  learning  curve  for  MIS  personnel 

•  Significantly  more  complicated  migration 
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•  Client/server  middleware  reliability  issues 

•  Unproven  scalability 

•  Many  more  variables— highest  risk 

D.  RELATION  OF  TECHNOLOGY  PLATFORM  TO  APPLICATIONS  AND 

BUSINESS  FUNCTIONS 

The  business  -ocations  and  their  definitions  are  less  germane  to  this  particular 
application  of  the  EAP  method  than  they  would  have  been  for  a  true  enterprise  level 
redesign.  Since  the  MCI  project  is  only  being  implemented  at  a  business  imit  level,  the 
location  of  all  pertinent  business  functions  is  the  Student  Services  Department  of  MCI. 
The  Deputy  Director,  the  MIS  Dept.,  the  Courseware  Development  Dept.,  and  all  the 
various  conceptual  sections  of  SSD  will  need  access  to  the  information  and  its 
applications.  While  the  data  wiU  physically  reside  on  a  central  server,  different  applications 
will  reside  on  different  clients.  Functionally,  the  SSD  is  broken  down  into  biUets  which 
perform  various  duties,  and  for  the  purpose  of  this  discussion  will  be  considered 
“sections”  of  SSD,  although  there  may  be  no  realistic  corresponding  organizational 
structure  for  these  conceptual  business  functions. 

All  sections  of  the  SSD  are  located  in  the  confines  of  the  SSD  operational  area  at 
MCI  headquarters.  The  conceptual  business  functions  performed  under  the  SSD  are: 

•  Grading  materials 

•  Process  Unit  Activity  Report 

•  Enroll/Di senroll  Students 

•  Perform  Registrar  functions 
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•  Process  Incoming  mail/e-mail 

•  Process  Incoming  phone  calls 

•  Provide  input  to  error  listing  for  MIS 

While  these  business  functions  are  all  the  responsibility  of  SSD,  they  may  be 
subdivided  into  notional  sections  that  are  staffed  by  different  personnel  but  retain  an 
assigned  business  tasking.  The  registrar  section  performs  registrar  functions.  The 
Immediate  action  section  provides  the  processing  of  incoming  phone  calls.  The  grading 
section  performs  the  grading  of  materials.  The  process  section  provides  for  the 
enroUment/disenroUement  of  students  and  processes  incoming  mail/e-mail.  The  Unit 
Servicing  section  processes  UAR’s  and  provides  input  to  MIS  for  the  purpose  of  the  error 
listing  report. 

Since  these  sections  are  somewhat  notional,  one  person  may  actually  perform  the 
duties  of  numerous  sections,  but  it  is  conceptually  useful  to  divide  them  functionally  for 
the  purpose  of  providing  technology  architecture  to  support  these  capability  requirements. 
The  assignment  of  proposed  applications  to  physical  locations  within  SSD  in  order  to 
support  the  business  processes  developed  in  [Ref.  4]  is  a  natural  extension  of  the  process 
methodology  used  in  this  report.  The  physical  distribution  of  clients  is  depicted  in  Figure 
5.  As  indicated  in  the  final  report  to  MCI  [Ref.  4],  the  clustering  of  the  CRUD  matrix 
developed  for  processes  and  their  related  entities  reveals  the  applications  required  by  each 
sub-unit  of  SSD.  These  applications  must  be  mapped  to  client  workstations  in  the 
MCIAIS  n  network.  Figure  5  shows  these  physical  locations  and  their  distributed 
application  requirements,  while  Table  1  presents  these  results  in  tabular  format. 
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and  their  distributed  application  requirements,  while  Table  1  presents  these  results  in 
tabular  format. 


The  intent  of  Figure  5  and  Table  1  is  to  illustrate  the  logical  distribution  of 
applications  to  the  physical  assets  recommended  for  SSD  and  to  determine  their 
approximate  location.  The  exact  location  of  the  client  workstations  or  the  resulting  work 
flow  issues  raised  as  they  apply  to  the  “To-Be”  system  are  left  to  the  system  implementers. 

One  technology  consideration  deliberately  left  out  of  this  architecture  definition 
per  the  instruction  of  MCI  was  the  potential  for  World  Wide  Web  enrollment/assistance 
requirements  for  the  Processing  subsection.  Although  this  requirement  has  been 
intentionally  excluded  due  to  MCI  planning  limitations,  it  should  be  addressed  by 
development  planners  for  MCIAIS II  as  soon  as  goals  and  plans  for  use  of  the  World 
Wide  Web  are  developed. 
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Applications 

Deputy  Director 

Executive  summary 

Executive  Summary 

Information,Office  Suite,E-mail 

MIS 

All 

DBMS,  All  Customer  Apps 

SSD  Mgmt 

AU 

Exec  Summary  Info,  Grading,  Student 
Servicing,  Unit  Servicing,  Office 
Suite,E-mail 

Registrar  Section 

Student,  Course, 
Program 

Registrar,  Office  Suite,  E-mail 

Grading  Section 

Student,  Course, 

Exam, 

Exam_Answer_Key 

Grading,  Office  Suite,  E-mail 

Immediate  Action 
Section 

Student,  Course, 
Customer,  Call, 

Student  Servicing,  Office  Suite,  E-mail 

Unit  Servicing 

Section 

Student,  Course, 
Program 

Unit  Servicing,  Student  Servicing, 

Office  Suite,  E-mail 

Process  Section 

Student,  Course, 
Program,  Exam, 
Exam_Answer_Key 

Student  Servicing,  Office  Suite,  E-mail 

Table  1.  Location/Entity/Application  Listing. 
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V.  THE  MIGRATION  PLAN 


The  formation  of  the  technology  architecture  is  a  critical  step  in  reaching  the 
desired  goal  of  a  new  information  system,  but  a  migration  strategy  to  reach  that  goal  is 
just  as  important.  This  chapter  will  discuss  migration  strategies  in  general,  some  of  the 
considerations  for  choosing  and  defining  a  migration  strategy,  and  finally  describe  the 
migration  strategy  for  MCI. 

A.  MIGRATION  STRATEGIES 

1.  IntroducJion 

The  MCIAIS  redesign  was  undertaken  because  of  the  inherent  inability  of  the 
existing  legacy  system  to  support  current  and  future  business  practices.  As  is  t3qpical  of 
legacy  systems,  the  underlying  data  structure  is  poorly  documented,  applications  have 
been  patched  repeatedly,  maintenance  costs  are  high  and  documentation  of  modifications 
to  data  structure  has  not  been  consistent.  Further,  the  current  IS  budget  is  being  spent  on 
the  maintenance  and  operation  of  the  current  legacy  IS  and  there  is  not  enough  funding  to 
finance  the  required  upgrade  to  migrate  the  system.  Brodie  and  Stonebraker  [Ref.  5] 
coined  the  term  IS  Apoplexy  to  describe  this  situation.  To  complicate  matters  fiuther,  the 
lack  of  flexibility  resicient  in  a  legacy  system  prevents  the  IS  department  from  integrating 
new  technologies  wid-  the  legacy  IS. 

Migration  to  open  systems  is  a  topic  of  much  discussion  in  technology 
publications.  By  recognizing  the  need  to  migrate  from  the  current  legacy  system',  MCI  has 
taken  a  strong  positive  step  towards  ensuring  their  future  viability  as  a  service  provider  to 
their  customers,  the  United  States  Marines. 
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Migration  of '  ;gacy  systems  to  contemporary,  open  architectures  is  a  difficult  task 
with  many  unanticipated  levels  of  complexity.  The  methodology  used  to  support 
migration  is  based  on  two  fundamental  approaches  to  the  issue  of  migration.  The  first 
approach,  known  as  the  cold  turkey  approach,  is  instantaneous  transition  from  the  legacy 
to  contemporary  system  and  the  second,  known  as  the  chicken  little  approach,  takes  a 
more  cautious  and  incremental  approach  to  migration.  These  two  approaches  are 
discussed  in  the  following  sections. 

2.  Cold  Turkey  Approach 

The  Cold  Turkey  strategy  is  so  named  because  it  is  analogous  to  a  smoker  who 
quits  “cold  turkey”.  It  means  that  the  target  IS  will  be  developed  from  scratch  using 
modem  software  techmques  and  new,  different  hardware.  There  is  no  interaction  between 
the  legacy  system  and  the  target  IS,  and  the  intent  is  that  when  the  target  information 
system  is  ready,  operations  will  be  cutover  from  one  system  to  the  other.  This  cutover  is 
inherently  risky,  and  the  overall  strategy  of  cold  turkey  has  other  impediments  to  success 
as  identified  by  Brodie  and  Stonebraker  [Ref.  5].  These  impediments  include: 

•  The  system  must  be  better,  not  just  newer. 

•  Business  conditions  don’t  stand  still  while  the  target  system  is  being  developed. 

•  There  are  rarely  specifications  documented  on  the  legacy  system.  Often  the 
only  documentation  is  the  code  itself. 

•  There  are  numerous  undocumented  dependencies  between  applications. 

•  The  size  of  legacy  system  data  may  prevent  timely  cutover  on  mission  critical 
systems. 

•  Managing  large  projects  is  hard. 
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Lateness  is  seldom  tolerated. 


•  Large  projects  tend  to  bloat. 

•  Homeostasis  is  prevalent  in  the  IT  world.  Fear  of  change,  new  techniques  and 
new  technologies  contribute  to  enormous  resistance  to  cold  turkey  migration. 

•  Analysis  paralysis  sets  in.  Migration  doesn’t  begin  until  you  understand  the 
legacy  s>  slem. 

The  primary  ;  /lortfall  of  cold  turkey  migration  is  that  there  is  no  period  of  gradual 
adjustment  or  flexible  adaptation  to  the  new  system.  The  actual  cutover  is  incredibly  risky 
—  the  mission  critical  information  system  will  be  turned  off  and  operations  will  begin  on  a 
new  system  with  the  potential  for  untested  bugs.  Very  few  organizations  can  afford  this 
level  of  risk.  While  it  is  not  unreasonable  under  the  current  operating  environment  for 
MCI  to  suspend  operations  for  a  short  period  while  cutover  and  testing  occur,  the  many 
other  disadvantages  make  this  option  unattractive,  and  therefore  is  not  recommended  for 
MCI.  An  incremental  strategy  is  more  suitable  as  discussed  in  the  following  section. 

3.  Chicken  Little  Approach 

The  incremental  migration  strategy  is  named  for  the  fabled  character  with  the 
cautious,  conservative  view  of  the  world.  Brodie  and  Stonebraker  feel  that  this  type  of 
cautious  and  conservative  approach  is  necessary  to  ensure  the  smooth  running  operation 
required  of  a  successful  migration  effort.  According  to  this  strategy  the  legacy  system  is 
migrated  in  place  in  small  incremental  steps  until  the  desired  long  term  objective  is 
reached.  Each  step  requires  smaller  resource  allocation  and  less  time  to  complete  than  a 
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cold  turkey  approacL  Because  the  strategy  is  incremental,  the  risk  associated  with  the 
migration  is  also  incremental  and  is  divided  between  each  of  the  steps.  The  smaller  the 
increment  of  migration,  the  smaller  the  risk  to  the  system,  but  also  the  smaller  the  potential 
gain  for  the  system  owners.  By  dividing  the  risk,  the  organization  is  insulated  from  the 
effects  of  the  failed  migration  in  total.  If  a  chicken  little  step  fads,  only  that  step  has  to  be 
repeated.  Brodie  and  Stonebraker’s  eleven  chicken  little  steps  (discussed  later  in  detail) 
are  as  follow; 

1 .  Incrementally  analyze  the  legacy  IS. 

2.  Incrementally  decompose  the  legacy  IS  structure. 

3.  Incrementally  design  the  target  interfaces. 

4.  Incrementally  design  the  target  applications. 

5.  Incrementally  design  the  target  database. 

6.  Incrementally  install  the  target  environment. 

7.  Incrementally  create  and  install  the  necessary  gateways. 

8.  Incrementally  migrate  the  legacy  database. 

9.  Incrementally  migrate  the  legacy  applications. 

10.  Incrementally  migrate  the  legacy  interfaces. 

1 1 .  Incrementally  cut  over  to  the  target  IS. 

Like  any  other  complex  plan  or  strategy,  migration  requires  an  underlying  set  of 
fundamental  principles  to  guide  the  effort  towards  success.  Some  examples  provided  by 
Brodie  and  Stonebraker  [Ref.  5]  of  migration  requirements  for  a  typical  legacy  system 
include: 
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•  Migrate  iii  place. 

•  Ensure  continuous,  safe,  reliable,  robust,  ready  access  to  mission 
critical  functions  and  information  at  performance  levels  adequate  to 
support  the  business  workload. 

•  Make  as  many  fixes,  improvements,  and  enhancements  as  reasonable  to 
address  current  and  anticipated  requirements. 

•  Make  as  few  changes  as  possible  to  reduce  migration  complexity  and 
risk. 

•  Alter  the  legacy  code  as  little  as  possible  to  minimize  risk. 

•  Alter  the  legacy  code  as  required  to  facilitate  migration. 

•  Establish  as  much  flexibility  as  possible  to  facilitate  future  evolution. 

•  Minimize  the  potential  negative  impacts  of  change,  including  those  on 
users,  applications,  databases,  and  in  particular,  on  the  ongoing 
operations  of  the  mission  critical  IS. 

•  Maximize  the  benefits  of  modern  technology  and  methods. 

By  addressing  these  requirements  properly,  a  framework  for  successful  migration 
can  be  developed  for  MCI.  While  this  list  may  not  be  inclusive  of  aU  migration 
requirements,  it  reflects  a  good  framework  for  any  migration  effort. 

4.  Complexity  of  Architectures 

As  important  as  the  migration  strategy  and  incremental  philosophy  may  be,  the 
inherent  complexity  of  the  legacy  IS  architecture  must  be  considered  when  conducting 
luigration  planning.  As  stated  by  Brodie  and  Stonebraker,  any  IS  can  be  decomposed  into 
three  basic  levels.  Tlvese  are  the  interface  components,  the  application  components,  and 
the  database  components.  The  degree  of  dependency  between  these  three  components 
will  impact  significantly  on  the  ease  of  migration.  Legacy  systems  that  were  designed 
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without  the  benefit  of  modem  analysis,  design,  and  programming  methods  lack  the 
modularity  and  independence  of  modules  that  are  incorporated  into  current  stmctured 
development  techniques. 

Brodie  and  Stonebraker  categorize  systems  into  three  ascending  levels  of 
complexity:  decomposable,  semi-decomposable,  and  nondecompo sable.  The  type  of 
system  structure  determines  the  migration  steps  and  actions  taken  under  those  steps. 

A  decomposable  system  is  the  easiest  to  migrate  because  the  interfaces, 
applications  and  database  are  separate  with  well  defined  interfaces  between  them. 
Interdepencies  do  not  exist  between  the  applications  and  the  applications  interface  only 
with  the  database.  There  is  no  hierarchical  structure  among  the  applications,  and  all 
modules  are  documented  with  their  relationships.  Unfortunately,  this  structure  rarely 
exists  in  legacy  systems. 

The  next  type  of  system  in  ascending  order  of  difficulty  for  migration  is  a 
seini-decomposable  system.  In  this  type  of  system,  the  user  interfaces  and  system 
interfaces  are  separate  modules,  but  the  applications  and  database  cannot  be  separated. 
This  dependency  may  be  the  result  of  older  development  methods,  poor  systems 
engineering,  or  nonexistent  documentation. 

In  a  nondecomposable  system,  the  entire  system  is  built  without  documented 
dependencies.  It  may  be  viewed  from  the  migration  planner  as  a  “black  box”  with  no 
separate  modules.  A  system  that  combines  characteristics  of  both  decomposable  and 
nondecomposable  systems  is  labeled  a  “hybrid”  system.  This  type  of  system  indicates  that 
some  applications  ha'/e  no  modular  development,  and  contain  undocumented 
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dependencies  with  the  database.  Some  other  applications  are  decomposable  at  some  level, 
modular  and  not  dependent  on  the  database  or  other  applications. 

Based  on  its  characteristics,  MCIAIS  can  be  classified  as  a  semi-decomposable 
system.  On  one  hand  there  is  a  high  level  of  undocumented  dependencies  between  various 
applications  and  the  database  level  that  create  a  large  obstacle  in  decomposing  the  system 
for  easy  migration.  Qti  the  other  hand,  many  system  interfaces  and  user  interfaces  have 
been  developed  recently  and  can  be  considered  separate  modules. 

B.  MIGRATION  CONSIDERATIONS 

I.  Role  of  Gateways 

A  key  requirement  of  successful  migration  is  to  view  and  operate  the  legacy 
system  and  the  target  system  as  a  composite  information  system,  providing  the  critical 
business  functions  together  until  migration  can  be  completed.  The  key  component  in  the 
ability  to  operate  in  a  collective  environment  is  a  gateway.  A  gateway  is  specially 
developed  software  that  provides  an  interface  between  the  two  systems  while  insulating  • 
certain  components  from  changes  being  made  to  other  components.  The  gateway  must  be 
able  to  translate  data  and  function  requests  between  the  various  components,  and 
coordinate  updates  so  that  data  remains  accurate  and  consistent  in  both  the  old  and  target 
IS. 

The  gateway  will  need  to  insulate  the  legacy  interface  from  changes  made  to  the 
other  parts  of  the  legacy  IS.  This  insulation  should  provide  transparency  to  the  user,  who 
will  not  be  able  to  determine  whether  the  legacy  IS  or  the  target  IS  is  executing  certain 
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functions.  This  is  a  critical  feature  of  the  gateway  that  must  be  available  in  order  to 
successfully  implement  the  incremental  approach  to  migration.  Queries  and  updates  must 
be  translated  between  the  old  and  new  systems,  maintaining  accuracy  and  consistency  of 
data.  The  transaction  management  capability  of  the  gateway  must  be  able  to  guarantee  to 
the  user  that  the  integrity  of  the  mission  critical  data  is  being  maintained  during  the 
migration  process. 

Gateways  can  be  functionally  classified  as  either  forward,  reverse,  or  bi-directional, 
depending  on  their  direction  of  translation.  Forward  gateways  enable  the  legacy  interfaces 
to  access  data  on  the  target  system.  Forward  gateways  are  used  for  translating 
instructions  from  the  old  sys.tem  forward  to  the  target  system.  Reverse  gateways  direct 
data  in  the  opposite  way.  Instructions  received  on  the  target  interface  are  translated  in 
reverse  to  the  legacy  system.  Bi-directional  gateways  support  translation  in  both 
directions,  and  are  intuitively  the  most  complex.  During  the  migration  process, 
functionality  of  both  forward  and  reverse  gateways  is  required  at  some  point  to 
incrementally  migrate  systems.  With  a  bi-directional  gateway,  these  functionalities  are 
incorporated  in  one  product. 

The  bi-directional  gateway  supports  the  concept  of  parallel  operations,  i.e.,  the 
two  databases  operate  simultaneously,  replicating  transactions  received  on  either  database 
over  to  the  other  database.  To  successfully  implement  incremental  migration,  MCI  must 
use  a  gateway  that  will  support  the  parallel  operation  concept.  There  will  be  a 
requirement  to  synchronize  the  data  between  the  two  database  systems,  and  a  requirement 
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to  replicate  all  transactions  from  either  system  interface  during  the  migration 
implementation. 

Operating  two  heterogeneous  databases  simultaneously  is  not  trivial.  For  the  user 
to  remain  unaffected  by  the  migration,  there  must  be  complete  transparency  between  the 
two  databases.  Current  gateway  products  provide  for  simphfied  procedures  and 
programiTung  which  h  ive  significantly  improved  the  capability  of  interaction  between 
databases.  A  parallel  operation  must  be  able  to  keep  the  data  between  the  heterogeneous 
databases  synchronized,  but  in  doing  so,  allow  the  gateway  to  be  the  central  point  of 
management  for  updates  to  data  structure  and  location. 

Expectations  of  the  gateway  product  should  include  a  capability  or  some  type  of 
dynamic  dictionary  mapping  to  ensure  the  data  structure  of  the  legacy  and  target  systems 
are  synchronized,  and  must  be  able  to  guarantee  transactional  integrity  so  that 
communication  losses  do  not  result  in  inconsistent  data  between  the  heterogeneous 
databases.  Automatic  replication  is  another  expectation  of  gateway  products.  Any 
gateway  used  should  be  able  to  automatically  replicate  data  from  a  specified  source  (such 
as  tables  populated  from  MCTFS)  and  ensure  that  the  heterogeneous  databases  are  all 
synchronized  with  the  input  data  from  the  replication  source. 

The  placement  of  the  gateway  in  the  architecture  affects  the  complexity  of  the 
migration  effort  and  is  determined  by  the  potential  decomposition  of  the  legacy  IS  (see 
Figure  6).  If  the  system  is  decomposable,  the  gateway  can  be  placed  between  the 
applications  and  the  database,  and  functions  as  a  database  gateway.  For  a 
semi-decomposable  system,  the  gateway  is  labeled  an  application  gateway,  and  must  be 
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placed  between  the  interfaces  and  the  rest  of  the  legacy  IS.  The  last  type  of  Gateway  is 
called  an  IS  gateway,  because  it  interfaces  the  entire  legacy  IS  with  the  target  IS.  Because 
of  the  inherent  complexity  of  nondecomposable  system  migration,  this  gateway  type  is  the 
most  complex. 


2.  Migration  Cutover 

Cutover  is  the  key  difference  between  cold  turkey  and  incremental  migration. 
Because  the  cutover  of  the  system  carries  the  highest  level  of  risk  exposure  for  the 
organization,  it  must  be  considered  incrementally  in  concert  with  the  rest  of  the  migration 
philosophy.  The  decision  must  be  made  to  incrementally  cutover  to  the  new  IS  as  the 
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target  IS  applications  axe  tested  and  approved.  These  cutovers  can  be  accomplished  by 
organizational  applications  or  by  logical  units  of  functionality.  Decisions  for  incremental 
cutover  can  be  made  for  the  applications  discussed  in  Chapter  IV  for  the  physical 
locations,  or  can  be  applied  to  logical  applications  across  their  physical  boundaries. 

3.  Version  Control  and  Configuration  Management 

The  entire  migration  process  must  include  consideration  for  the  requirements  for 
improving  version  control  and  configuration  management  of  both  the  legacy  IS  and  the 
target  IS  during  all  steps  of  migration,  but  especially  during  the  cutover  step.  The 
developers  must  consider  version  control  of  code  that  is  being  developed  to  run  on  two 
separate  platforms,  and  maintain  current  documentation  on  this  temporary  code  to  ensure 
that  failed  steps  can  be  properly  analyzed  with  complete  documentation  of  the  transition 
code. 

C.  MIGRATION  STRATEGY  FOR  MCI 

As  discussed  before,  the  chicken  little  strategy  is  the  recommended  strategy  for  the 
incremental  migration  from  MCIAIS  I  to  MCIAIS  II.  Figure  7  (reproduced  from 
Migrating  Legacy  Systems,  pp  32,  [Ref.  5]),  displays  the  potential  paths  for  the  steps  used 
during  migration.  Many  of  these  steps  can  be  executed  in  parallel,  and  the  simultaneous 
completion  of  the  different  steps  can  reduce  the  overall  migration  time  frame.  Each  of 
these  steps  in  the  inci  emental  migration  strategy  is  discussed  in  detail  in  the  following 
section. 
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1 .  Incrementally  analyze  the  legacy  IS. 

2.  Incrementally  decompose  the  legacy  IS 
structure. 

3.  Incrementally  design  the  target  interfaces. 

4.  Incrementally  design  the  target 
applications. 

5.  Incrementally  design  the  target  database. 

6.  Incrementally  install  the  target 
environment. 

7.  Incrementally  create  and  install  the 
necessary  gateways. 

8.  Incrementally  migrate  the  legacy  database. 

9.  Incrementally  migrate  the  legacy 
applications. 

10.  Incrementally  migrate  the  legacy 
interfaces. 

1 1 .  Incrementally  cutover  to  the  target  IS . 

Figure  7.  The  Steps  of  the  Chicken  Little  Migration  Plan. 

1.  The  11  Steps 

As  indicated  earlier,  there  are  eleven  steps  that  establish  the  framework  for 
an  incremental  migration  plan.  What  follows  is  a  brief  discussion  of  those 
steps,  and  their  application  at  MCI. 

a.  Incrementally  Analyze  the  Legacy  IS 

This  first  step  is  especially  important  to  identify  as  many  dependencies 

between  the  applications  and  the  database  as  possible.  A  strong  “As  Is”  model  will 

greatly  increase  the  probability  of  success  for  the  new  IS.  It  is  important,  however,  to 

resist  analysis  paralysis  that  is  usually  the  result  of  an  overwhelming  feeling  that  one 

needs  to  conduct  further  analysis  to  completely  understand  the  legacy  system.  This  effort 

is  considered  comple'e  once  the  essence  of  the  business  rules  and  data  requirements  have 

been  captured.  The  majority  of  this  step  has  been  completed  for  the  SSD  portion  of 
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MCIAIS  II.  The  design  team  must  still  conduct  some  analysis  to  verify  and  validate  the 
delivered  models  and  documents. 

b.  Incrementally  Decompose  the  Legacy  IS  Structure 

The  amount  of  effort  here  must  be  governed  by  the  anticipated  time 
expected  to  conduct  the  migration.  If  the  legacy  system  is  intended  for  relatively  short  use 
(as  at  MCI)  then  it  probably  does  not  make  sense  to  put  a  great  deal  of  effort  into 
rewriting  code  on  the  legacy  system  to  facilitate  decomposition.  The  migration  team 
needs  to  identify  key  dependencies  that  will  impact  on  the  gateway  operations,  and  recode 
them  to  support  the  gateway  requirements  for  parallel  operations.  In  the  case  of  MCIAIS 
I,  the  in-house  programmers  should  be  familiar  enough  with  the  legacy  code  to  assist  a 
migration  team  in  the  necessary  redesign  of  the  code  to  support  this  decomposition. 

c.  Incrementally  Design  the  Target  Interfaces 

For  this  step,  the  planner  must  decide  which,  if  any,  of  the  user  and  system 
interfaces  on  the  legacy  system  will  be  migrated  to  the  new  system.  For  MCIAIS  I,  the 
user  interfaces  will  be  developed  from  scratch  using  functional  requirements  developed 
from  user  input  and  the  information  required  as  demonstrated  in  legacy  user  interfaces. 
The  interface  is  poor  enough  on  MCIAIS  I  that  significant  user  resistance  is  not 
anticipated  to  the  change  of  user  interface.  The  graphical  user  interface  being  developed 
wOl  be  much  easier  to  use,  and  the  gateway  will  allow  the  users  to  access  old  data  from 
the  legacy  system  while  the  new  system  is  under  development. 
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d.  Incrementally  Design  the  Target  Applications 

The  target  application  designs  are  completed  to  conform  with  the  business 
rules  adopted  and  defined  under  step  one.  Any  business  rules  adopted  for  applications 
must  be  enforceable  on  the  target  environment.  New  business  rules  that  did  not  exist  in 
the  old  system  bring  with  them  some  element  of  risk  to  add  them  to  the  new  application. 
On  the  other  hand,  the  ability  to  institute  these  mles  may  be  a  predominate  factor  in 
migrating  the  system  in  the  first  place,  so  the  evolution  of  business  rules  in  the  new 
applications  must  be  carefully  considered.  Adding  new  data  entities,  for  instance,  may  be 
much  higher  risk  activity  than  simply  installing  a  graphical  user  interface  on  the  old 
system,  but  reflects  a  fundamental  requirement  that  is  driving  the  migration  process,  as  is 
found  in  this  project.  For  MCIAIS  II,  the  target  system  would  not  be  acceptable  without 
these  higher  risk  modifications.  The  Oracle®  DBMS  provides  a  high  level  of  functionality 
to  support  the  business  rule  requirements  in  the  form  of  triggers  and  stored  procedures. 

e.  Incrementally  Design  the  Target  Database 

The  database  model  should  be  built  with  a  thorough  understanding  of  the 
data  requirements  of  the  organization.  These  requirements  most  likely  exceed  the  data 
currently  stored  in  the  legacy  system.  The  design  team  must  be  prepared  to  provide 
extensive  documentation  and  version  control  to  ensure  the  documentation  lapses  of  the 
legacy  system  are  not  duplicated.  This  is  especially  important  as  application  development 
modifications  occur  later  in  the  implementation  phase.  Tools  for  database  development 
should  be  incorporated  to  insure  synchronization  between  the  database  models  and  the 
actual  program.  As  discussed  in  the  final  project  report  [Ref.  4]  the  ERwm®  product 
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provides  a  high  level  of  synchronization  capability  between  the  data  model  and  the  Oracle® 
operational  schema. 

/.  Incrementally  Install  the  Target  Environment 
The  target  environment  must  be  defined  based  on  the  aggregate 
requirements  of  the  total  target  system.  Development  should  begin  as  if  the  target 
environment  is  being  developed  from  scratch  without  the  benefit  of  any  code  or 
information  from  the  legacy  system.  One  of  the  most  visible  changes  in  the  target 
environment  will  be  replacing  the  “dumb  terminals”  with  either  networked  client  PC’s  or 
workstations.  Once  the  target  environment  is  selected,  it  should  be  installed  incrementally 
to  minimize  risk  and  give  users  time  to  adapt  to  the  new  system.  This  portion  of  the 
migration  is  very  expensive,  as  it  involves  replacing  all  of  the  hardware  and  system 
software  for  each  user.  It  is  also  the  most  visible  element  of  the  migration  to  the  system 
users,  as  it  takes  place  on  their  desktop.  Because  this  step  involves  the  adaptation  of  users 
and  management,  it  can  easily  become  the  longest  step  in  the  migration  process,  hampered 
by  human  politics  and  psychology.  The  majority  of  the  hardware  costs  for  this  step  have 
already  been  incurred  for  the  users.  Minimal  costs  for  additional  upgrades  as  required 
should  be  expected  and  included  in  future  budgets. 

g.  Incrementally  Create  and  Install  the  Necessary  Gateways 
If  commercial  products  are  not  available  for  this  step,  it  will  be  the  most 
technically  challenging  portion  of  the  migration.  If  the  organization  can  obtain 
commercially  produced  gateways  in  support  of  their  migration  plan,  chances  for  success 
will  be  greater  than  if  the  gateways  must  be  developed  from  scratch.  Increasingly,  more 
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commercial  products  are  available,  as  are  experienced  migration  specialists  to  support  the 
migration  process.  In  conferring  with  one  of  the  methodology  authors,  he  indicated  that 
gateway  development  has  improved  and  many  more  successful  migration  efforts  have  been 
recorded  [Ref.  6].  Statistics  on  these  efforts  were  unavailable  at  the  time.  The  availability 
of  commercial  gateways  and  potential  solutions  for  this  effort  will  be  addressed  later  in 
this  chapter,  but  theii  ability  to  satisfy  this  requirement  is  fully  anticipated. 
h.  Incrementally  Migrate  the  Legacy  Database 
With  a  gateway  in  place,  one-time  migration  of  the  data  can  begin. 
Depending  on  the  strategy  chosen,  the  organization  can  choose  to  populate  the  target 
database  once,  and  discontinue  active  use  of  the  legacy  database,  or  the  organization  can 
take  advantage  of  the  replication  features  of  the  gateway  and  use  whichever  portion  of  the 
database  best  supports  the  logical  migration  of  user  applications. 

The  implementation  of  a  one  time  migration  is  more  closely  associated  with 
a  cold  turkey  migration  strategy,  but  can  be  adapted  to  an  incremental  migration  strategy 
as  well.  For  MCI,  a  data  migration  plan  using  a  gateway  is  the  preferable  method. 

Data  migration  follows  three  basic  steps:  1)  Identification  of  attributes 
currently  available;  2)  Mapping  and  migration  of  currently  available  attributes  to  the 
newly  developed  database;  and  3)  automatic  input  of  attributes  not  currently  available  at 
some  future  time  (once  they  become  available  through  automation  and  redesign  of  other 
MCI  systems  and  departments),  or  manual  input  of  attributes  not  currently  available  and 
not  likely  to  be  made  available  through  the  automation  of  other  MCI  systems  or 
departments. 
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i.  Incrementally  Migrate  the  Legacy  Applications 

For  steps  9, 10,  and  1 1  in  a  semi-decomposable  system,  the  development 
team  can  choose  to  conduct  all  three  steps  together,  or  attempt  to  find  logical  divisions  in 
the  applications.  By  definition,  the  semi-decomposable  legacy  system  resists 
decomposition  of  the:  e  layers,  so  the  migration  will  necessarily  be  dependent  on  the  ability 
of  the  development  te  im  to  separate  the  applications  from  the  data.  Since  no  actual 
application  code  is  being  migrated  for  this  effort,  the  application  migration  is  addressed  in 
natural  divisions  of  w(.irk/organization.  As  the  development  team  completes  and  tests 
applications,  they  can  submit  them  to  the  SSD  sub-units  that  are  the  intended  users  of  the 
applications. 

After  iterative  user  testing,  these  applications  can  be  migrated  to  the  user  in 
segmented  sections,  such  as  migrating  the  processing  application  first,  then  the  grading 
application,  etc.,  or  the  total  application  for  a  functional  area  can  be  migrated  to  some  of 
the  desktops.  For  example,  some  of  the  Customer  Service  desktops  could  be  migrated, 
leaving  dumb  terminals  on  other  desktops  to  facilitate  more  thorough  testing  and  user 
adaptation.  This  plan  will  have  to  be  developed  by  the  design  and  implementation  team 
after  some  of  the  application  development  has  been  completed. 

j.  Incrementally  Migrate  the  Legacy  Interfaces 

The  dumb  terminals  represent  the  primary  user  interface  with  the  system, 
and  can  be  replaced  on  some  of  the  desktops  immediately  upon  new  interface 
development.  Minimal  numbers  of  dumb  terminals  may  need  to  be  retained  for  periods  of 
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non-availability  during  development  of  the  target  IS.  The  gateway  will  replace  the 
primary  application  interfaces  and  maintain  the  required  synchronization  of  the  legacy  and 
target  databases. 

k.  Incrementally  Cutover  to  the  Target  IS 

As  discussed  previously,  the  cutover  can  be  accomplished  by  organization 
section  applications  or  by  logical  units  of  functionality.  The  key  to  this  step  is  taking  the 
cutover  in  small  enough  pieces  to  manage  effectively.  It  is  important  that  no  major 
portions  of  the  system  be  cutover  simultaneously.  Doing  so  will  raise  all  of  the  risk 
factors  associated  with  cold  turkey  migration.  The  cutover  can  be  integrated  with  the  test 
plan  to  accomplish  the  module  cutover  in  conjunction  with  successful  testing.  By  limiting 
the  size  of  cutover  modules,  it  wiU  also  give  users  more  time  to  train  for  and  adapt  to  the 
new  system. 

2.  Hardware  Migration  Issues 

The  next  area  for  development  of  migration  strategy  is  the  consideration  of 
hardware  related  issues.  All  three  options,  discussed  previously  in  Chapter  IV,  require 
hardware  changes  that  must  be  incorporated  into  the  overall  migration  strategy.  MCI 
currently  is  operating  a  Hewlett-Packard  3000  model  957.  This  is  the  baseline  hardwzue 
platform.  The  migration  path  for  hardware  is  determined  by  which  of  the  three  previously 
defined  options  is  chosen. 

a.  Option  One 

This  option  requires  either  upgrading  the  current  minicomputer  by  adding 
memory  and  storage  capacity,  or  migrating  to  a  HP  3000  model  200,  which  we  believe  is 
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an  overkill  for  the  requirements  of  this  migration  effort.  This  minor  upgrade  option 
provides  a  familiar  hardware  environment,  and  would  have  the  lowest  impact  and  lowest 
risk  of  any  of  the  options. 

b.  Option  Two 

The  second  option  provides  for  transitioning  the  current  system  to  a  HP 
900  model  969  minicomputer.  This  is  a  relatively  familiar  hardware  environment,  but  does 
have  significant  hardware  distinctions  from  the  HP  3000  environment.  This  computer 
model  represents  a  significant  upgrade  in  processing  capacity  and  will  provide  computing 
power  for  MCI  for  m  my  years.  The  overall  cost  of  this  option  is  very  high,  which  is 
categorized  as  medium  risk. 

If  this  option  is  chosen,  migration  will  require  moving  the  existing  legacy 
system  from  the  old  hardware  to  the  new  hardware.  Although  this  step  represents  an 
operating  system  change,  in  addition  to  a  hardware  change,  technical  representatives  from 
the  vendor  are  expected  to  support  the  effort  of  porting  the  legacy  system  in  its  current 
form  to  the  new  hardware.  The  new  hardware  base  will  need  to  be  integrated  with  MCI’s 
local  area  network  and  will  also  need  connectivity  to  the  MCTFS  database. 

c.  Option  Three 

The  third  option  represents  the  desired  end  state  for  MCI  and  is  based  on 
an  Intel  microcomputer  running  on  a  Windows  NT  server.  This  configuration  represents 
a  new  hardware  suite  which  will  require  additional  training  and  vendor  assistance  during 
the  migration  effort.  MCI  must  be  willing  to  support  comprehensive  training  of  MIS 
personnel  in  both  hardware  and  software  to  ensure  the  success  of  this  option.  Because  of 
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the  steep  learning  curve  for  MIS  personnel,  this  option  is  best  suited  for  incremental 
migration  over  a  period  of  time  and  preceded  by  option  one.  Selecting  this  option  initially 

is  categorized  as  very  high  risk. 

3.  Software  Migration  Issues 

All  three  options  address  a  change  in  the  DBMS  software,  and  two  of  the  options 
discuss  changes  in  operating  system  software.  These  changes  must  be  incorporated  into 
the  overall  migration  strategy. 

a.  Option  One 

Option  one  does  not  require  operating  system  migration.  Retaining  the 
current  operating  system  greatly  reduces  migration  risks  by  providing  personnel  with  a 
familiar  system  environment.  Current  applications  can  be  retained,  but  the  current 
Turboimage  database  will  require  migration  to  an  Oracle®  relational  DBMS,  and  this  step 
is  common  to  each  option.  The  straightforward  advantage  of  the  easy  software  migration 
path  is  enough  to  make  option  one  the  best  choice  for  MCI,  as  well  as  the  lowest  level  of 
risk. 

b.  Option  Two 

Option  two  provides  for  a  transition  of  operating  systems  from  MPE/iX  to 

HPAJX.  Because  MCI  personnel  are  not  trained  in  HP/UX  there  will  have  to  be 

significant  investment  in  personnel  training  to  facilitate  the  operational  knowledge 

required  of  system  administrators  of  a  UNIX  based  system.  Current  applications  will  have 

to  be  reprogrammed  for  HP/UX  or  rewritten  at  an  unknown  cost.  While  UNIX  platforms 

are  certainly  open,  transition  to  UNIX  minicomputers  is  not  the  direction  of  the  computer 
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industry.  Because  of  the  training  costs  and  application  software  costs,  this  operating 
system  transition  is  characterized  as  high  risk,  and  may  be  a  potential  point  of  failure  for 
this  project. 

c.  Option  Three 

Option  three  is  a  transition  to  a  Windows  NT  operating  system  based  on  a 
microcomputer  platform.  While  it  carries  the  same  risks  as  option  two,  the  low  cost  of  the 
hardware  platform  and  operating  system  allows  for  small  scale  implementation,  thus 
providing  more  time  for  MIS  personnel  to  be  trained  and  prepared  to  run  this  system. 
Because  of  the  overlap  in  operating  systems  between  all  the  servers  at  MCI,  it  would  be 
possible  to  train  all  MIS  personnel  in  the  operation  of  all  the  servers  at  MCI,  instead  of 
the  current  division  between  the  minicomputer  personnel  and  microcomputer  personnel. 

A  standard  operating  system  represents  consolidated  training  costs,  and  lower 
maintenance  costs.  Litegrated  properly  with  Option  one,  this  path  is  the  right  long-term 
solution  for  MCI. 

4.  Other  Software  Issues 

If  MCI  elects  to  transition  to  a  UNIX  environment  (HP/UX),  it  will  entail 
migrating  the  current  database  and  all  current  legacy  applications  from  MPE/iX  based 
software  to  HP/UX  based  software.  MCI  will  need  to  obtain  vendor  support  for 
migration  of  any  applications  that  are  not  supported  by  Hewlett-Packard.  In  order  to 
ensure  operational  stability  of  the  new  version  of  the  legacy  system,  this  step  needs  to  be 
completed  before  development  of  the  target  system  begins  on  the  new  platform.  This  will 
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create  a  critical  time  delay  for  MCI  during  a  period  when  personnel  are  attempting  to 
learn  to  manage  a  new  operating  system  and  integrate  new  hardware  systems. 

Failure  to  ensure  system  stability  could  seriously  jeopardize  the  entire  target 
development  effort.  After  the  operating  system  and  new  hardware  have  been  successfully 
installed,  the  next  step  is  to  migrate  the  HP/UX  Turboimage  database  to  a  relational 
database.  This  step  will  enable  MCI  to  incrementally  migrate  from  a  flat  file  system  to  a 
relational  table  based  database.  MCI  has  two  basic  choices  for  incremental  migration: 
either  migrate  the  Hf’/UX  Turboimage  database  to  HP/UX  Image/SQL  database,  then 
migrate  the  Image/SOL  database  to  an  Oracle®  database  or  migrate  from  Turboimage 
directly  to  an  Oracle**^  database. 

The  first  option  is  consistent  with  an  incremental  migration,  and  will  allow  MCI  to 
take  advantage  of  HP  support  for  both  products,  while  migrating  the  core  data  into  a 
relational  format  based  on  the  data  model  developed  by  the  NPS  team.  There  are 
commercial  firms  which  specialize  on  this  type  of  migration,  and  can  be  consulted  to  aid 
MCI  in  this  effort.  Upon  successful  completion  of  migration  to  Image/SQL,  MCI  can  . 
continue  to  plan  for  eventual  migration  to  an  Oracle®  relational  database  management 
system.  Oracle*  Corporation  supports  a  commercial  gateway  for  migration  to  Oracle® 
Server  7.3  from  Image/SQL  databases.  This  gateway  will  be  discussed  in  some  detail  later 
in  this  thesis. 

The  second  option  is  also  consistent  with  incremental  migration  and  eliminates  the 
costly  requirement  to  purchase  the  interim  software  for  Image/SQL.  By  purchasing  a 
direct  gateway  between  Turboimage  and  Oracle®  databases,  the  migration  transition 
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timeline  can  be  reduct:  d,  redesign  of  the  system  can  be  simplified,  and  support  for  longer 
term  migration  will  be  enhanced.  Commercial  solutions  are  available  for  this  type  of 
migration  and  are  discussed  later  in  this  chapter. 

D.  CONCLUSIONS 

Upon  consideration  of  the  issues  relating  to  migration,  several  conclusions  were 
reached  that  directly  impact  this  effort.  These  issues  need  consideration  by  MCI  in  order 
to  maximize  the  benefit  of  system  migration. 

1.  Preventing  New  Legacy  Information  Systems 

Unfortunately,  the  new  system  of  today  will  become  the  legacy  system  of 
tomorrow.  To  ease  tlie  pain  of  future  migration,  modern  analysis,  design,  and 
implementation  techniques  should  be  employed.  By  designing  clearly  documented 
modular  applications,  MCI  can  prevent  the  reoccurrence  of  the  very  difficult  migration 
path  that  exists  today.  As  indicated  in  Chapter  IV,  the  target  IS  must  be  designed  to  meet 
the  architectural  principles  under  which  this  project  was  begun.  MCIAIS  II  must  be 
portable  and  able  to  support  future  rightsizing  efforts.  No  one  can  predict  with  certainty 
the  future  business  requirements  for  MCI,  nor  the  future  capabilities  of  technology,  nor 
how  the  former  will  interface  with  the  latter.  By  developing  an  open,  scaleable,  portable 
system  that  leverages  flexibility  to  a  maximum,  MCI  can  position  itself  to  favorably  deal 
with  the  future. 

At  this  time  thetre  is  no  way  to  predict  the  role  of  the  World  Wide  Web  (WWW) 
on  how  MCI  will  eventually  support  students.  Rapid  development  in  distance  learning 
techniques  and  methods  may  render  MCFs  current  role  obsolete  in  a  few  short  years. 
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MCIAIS II  must  be  flexible  enough  to  adapt  to  the  direction  of  technology  and  changing 
roles  and  missions. 

2.  Continuing  Migration  to  PC  Platforms 

In  order  to  maximize  the  benefits  of  flexible  technology  and  capitalize  on  industry 
direction,  MCIAIS  D  can  only  be  seen  as  an  interim  step  in  a  continual  migration  process. 
Current  trends  in  the  development  of  microcomputer  servers  indicate  the  development  of 
four,  six  and  eventually  ten  processor  servers  which  will  exceed  the  planned  HP  9000 
minicomputer’s  processing  capabilities  for  much  less  capital  investment.  The  ability  to 
distribute  the  servers  and  the  application  processing  provides  significant  increases  in 
flexibility  and  availability,  while  providing  decreased  risk.  The  eventual  migration  to 
microcomputer  based  systems  wiU  align  MCI  with  industry  direction,  and  minimize  capital 
expenditures  for  the  future.  It  would  be  in  the  best  interest  of  MCI  to  begin  this  migration 
planning  immediately,  potentially  purchasing  the  first  server  in  1998  to  begin  development 
and  training  on  the  microcomputer  platforms.  Individual  applications  can  be  migrated 
seamlessly  to  other  platforms  using  the  Oracle®  Server  software. 

The  biggest  danger  of  the  purchase  of  the  new  HP  9000  is  that  MCI  planners  will 
tie  future  development  of  the  MCIAIS  to  the  sunk  cost  of  this  platform.  In  choosing  this 
platform,  MCI  did  not  address  the  full  life  cycle  cost  of  this  system.  The  high  maintenance 
costs  of  this  system  suggest  that  MCI  should  migrate  off  of  this  platform  at  the  first 
available  opportunity.  To  facilitate  this  migration,  the  earliest  implementation  of  a 
microcomputer  based  server  for  database  distribution  is  strongly  recommended. 
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3.  Potential  Commercial  Solutions 


There  are  two  potential  commercial  solutions  which  merit  further  discussion  as  a 
result  of  this  research.  The  first  potential  solution  is  an  Oracle®  Gateway  Solution,  the 
second  is  a  third  party  vendor  solution. 

a.  Oracle®  Gateway  Solution 

This  ^sateway  could  only  be  used  if  a  transition  from  Turboimage  to 
Image/SQL  is  condu  ted.  This  product  is  the  Oracle*  Transparent  Gateway  for 
Image/SQL.  All  indications  point  to  a  capable  gateway  product,  but  one  that  only  works 
in  the  SQL/Table  based  environment.  Oracle®  Corporation  markets  and  sells  customized 
gateway  solutions  that  claim  to  satisfy  the  same  requirements  as  the  commercially 
available  gateways,  but  at  a  greater  cost  due  to  the  customized  nature  of  the  product.  For 
the  discussion  of  this  gateway,  the  information  centers  on  the  capabilities  available  in  the 
transparent  gateway  available  for  Image/SQL  to  Oracle®  DBMS.  This  product  will 
support  read  and  write  access  to  the  Image/SQL  database  from  the  Oracle®  applications. 
Image  data  can  be  migrated  periodically  or  in  a  single  population  move  to  the  Oracle® 
database.  This  gateway  solution  will  support  the  migration  strategy  endorsed  in  this 
chapter,  but  will  require  the  installation  of  the  Oracle®  server  product  as  well  as  previous 
migration  of  the  database  to  Image/SQL  before  the  gateway  could  be  used.  Oracle® 
Corporation  indicates  that  it  is  investigating  potential  solutions  to  migrate  directly  from 
Turboimage,  but  none  are  commercially  available  at  this  time. 

The  Oracle®  gateway  solution  claims  to  support  transparency,  d5mamic 
dictionary  mapping,  and  complete  synchronized  automatic  replication.  Oracle®  gateways 
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implement  transactioiial  integrity  through  a  “two  phase  commit”  process.  This  mechanism 


insures  consistent  data  by  not  allowing  writes  or  updates  to  the  Oracle®  database  to  be 


“committed”  or  completed  without  verification  that  they  have  posted  to  the  legacy 


database  as  well  (see  Figure  8).  This  integrity  and  replication  capability  would  be 


especially  valuable  in  mirroring  the  data  found  in  the  MCTFS  tables,  the  conversant  tables, 


the  legacy  tables  and  the  target  tables.  This  gateway  capability  is  especially  interesting  for 


this  migration  project,  but  the  costs  and  risks  of  additional  migration  to  Image/SQL 


outweigh  the  potential  gains.  A  custom  gateway  solution  from  Oracle®  that  provides  the 


same  functionality  as  the  Transparent  Gateway  for  Image/SQL  should  be  thoroughly 


investigated. 


First,  a  temporary 
commitment  ol  data 
updates  is  made  to  the 
Oracle  database 


Next,  a  permanent 
committment  ol  data 
updates  is  made  to  the 
external  (legacy) 
database 


Finally,  a  permanent 
commitment  of  data 
updates  is  made  to  the 
Oracle  database. 


Figure  8.  The  Oracle  Two  Phase  Commit  Process. 
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b.  Third  Party  Gateway  Solution 


During  the  evolution  of  this  study,  only  one  potential  commercial  solution 
has  been  found  for  the  migration  of  data  directly  from  Turboimage  to  Oracle®,  this 
addressing  the  current  needs  of  MCI.  This  potential  solution,  available  from  Starvision 
Inc.,  is  a  gateway  application  that  provides  an  out  of  box  gateway  solution  for 
Turbo  Image  to  Oracle®  translation.  There  are  two  variants:  an  unidirectional  gateway  and 
a  bi-directional  gateway.  The  unidirectional  gateway  allows  users  of  the  Turboimage 
applications  to  update  the  Oracle®  database  or  allows  users  of  the  Oracle®  applications  to 
update  the  Turboimage  database,  but  not  both.  To  get  the  bi-directional  functionality,  the 
bi-directional  gateway  must  be  purchased.  This  product  provides  full  replication  of  data 
and  best  supports  the  parallel  migration  plan  in  its  current  fonn.  The  Starvision  product 
was  developed  internally  for  HP  and  has  been  improved  and  marketed  separately.  It 
specializes  in  MPE/iX  Turboimage  gateway  capability,  and  seems  to  be  the  most  logical 
fit  for  the  existing  requirements  at  MCI.  It  is  adaptable  to  other  environments  and  could 
be  used  to  support  HP/UX  Turboimage  as  well. 

Additional  advantages  of  this  product  on  an  HP  3000  include  significantly 
enhanced  performance  and  throughput  of  data  due  to  “Standby  Agents”  which  are  stand 
by  processes  that  are  run  before  the  actual  requests  are  made  by  the  user.  This  results  in 
predefined  data  views  being  available  much  more  quickly.  The  Starvision  gateway  is 
compatible  with  most  development  tools  chosen  for  client  side  development,  and'is  fully 
integratable  into  an  intranet  environment  due  to  its  open  system  design.  This  solution,  or 
any  other  gateway  that  will  support  this  type  of  requirement  is  the  type  of  middleware 
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needed  to  adopt  an  incremental  migration  from  the  current  database  to  an  Oracle® 
database  solution. 
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VI.  TRANSITIONAL  ANALYSIS  OF  THE  MCI  MIGRATION  EFFORT 


One  of  the  most  critical,  yet  often  overlooked  areas  of  potential  failure  in  a 
complex  migration  effort  is  the  proper  management  of  the  transition  itself.  Failure  to  take 
into  account  the  human  factors  of  nugration  is  potentially  the  most  problematic  area  that 
planners  will  have  to  overcome.  This  chapter  will  address  some  of  the  concerns  people 
have  when  encountering  change,  how  these  concerns  have  applied  to  the  MCI  project,  and 
some  actions  that  pla  mers  and  leaders  can  take  to  ensure  the  smoothest  possible  transition 
to  a  target  system. 

A.  OVERVIEV  OF  CHANGE 

The  business  world  of  today  is  rife  with  examples  of  organizations  that  have  failed 
to  meet  the  challenge  of  change.  A  successful  organization  must  initiate  change,  not  just 
react  to  it.  This  means  the  organization  must  know  its  people,  their  capabilities,  their  level 
of  training,  and  their  basic  disposition  towards  change.  All  too  often,  change  for  the 
organization  is  a  reaction  to  crisis,  and  must  be  implemented  in  the  crisis  state.  By 
strategically  incorporating  planned  change  into  long  term  systems  migration  efforts,  the 
organization  can  prepare  its  people  for  the  change  ahead,  and  allow  them  to  shape  the 
methods  and  means  of  transition. 

1.  Definitions  and  Descriptions 

The  Harvard  Business  School  has  defined  change  as  “a  planned  or  unplanned 
response  to  pressures  and  forces  [Ref.  7].”  These  “pressures  and  forces”  have  always 
been  around,  but  one  could  argue  that  the  dawn  of  the  information  age  has  increased  their 
intensity  and  frequency.  Organizations  operating  and  competing  in  the  information  age 
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must  be  prepared  to  keep  ahead  of  the  forces  shaping  the  information  world.  To  prepare 

an  organization  for  this  newly  required  mind  set,  leaders  must  incorporate  an  active 

transition  management  strategy  to  cope  with  the  inevitable  resistance  to  change. 

In  his  book  on  the  payoff  of  technology  for  today’s  CEO,  Hoffrnan  has  a  pointed 

address  on  the  resistance  to  technological  change. 

New  uses  of  information  technology  require  people  to  change  the  ways  in 
which  they  do  their  jobs,  and  most  people  resist  change.  They  resist 
change  because  they  are  comfortable  with  their  current  ways  of  doing 
things,  because  they  know  that  the  change  process  itself  will  be  painful,  and 
because  they  are  unsure  about  how  the  new  situation  will  work  out.  This  is 
particularly  tme  of  changes  that  add  information  technology  to  jobs  that 
did  not  previously  use  it.  Many  people  are  uncomfortable  with  computers, 
some  to  the  point  of  fear.  People  who  perceive  themselves  to  be  successful 
in  their  jobs  are  particularly  prone  to  resist  changing  the  ways  of  working 
that  helped  them  achieve  their  success  [Ref.  8]. 


The  last  sentence  of  Hoffman’s  statement  is  particularly  important  in  today’s 
world.  Increasingly,  successful  people  identify  themselves  with  their  careers.  Some 
studies  demonstrate  that  this  behavior  is  spreading  from  the  realms  of  the  elite  to  the 
lower  levels  of  organizations  as  well.  Nicholson  states,  “The  more  challenging,  complex, 
and  demanding  are  our  occupations,  the  more  likely  we  are  to  think  of  our  careers  not  as 
part  of  our  lives,  but  as  our  lives  [Ref.  9].’’  If  this  is  true,  then  surely  the  stakes  have  been 
raised  in  the  transition  state.  We  are  not  just  changing  our  jobs,  we  are  changing  our  lives. 

2.  The  Need  to  Hold  On 

People  resist  change  for  many  reasons.  It  might  be  due  to  lack  of  information 
about  the  change,  or  perhaps  it  originates  from  fear  that  the  change  will  bring  with  it  a 
loss.  One  of  the  first  aspects  of  resistance  to  address  is  the  need  to  hold  on.  This  means 
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holding  on  to  the  comfort  zone,  the  attitudes  and  behaviors  that  have  shaped  the 

successful  work  experience,  even  the  machinery  used  to  accomplish  this  work.  As  long 

ago  as  1961,  James  Baldwin  wrote  in  his  book: 

Any  real  change  implies  the  break  up  of  the  world  as  one  has  always 
known  it,  the  loss  of  all  that  gave  one  identity,  the  end  of  safety.  And  at 
such  a  moment,  unable  to  see  and  not  daring  to  imagine  what  the  future 
will  now  bring  forth,  one  clings  to  what  one  knew;  or  thought  one  knew;  to 
what  one  possessed  or  dreamed  that  one  possessed.  Yet  it  is  only  when 
man  is  able,  without  bitterness  or  self-pity,  to  surrender  a  dream  he  has 
long  cherishcf  i,  or  a  privilege  he  has  long  possessed,  that  he  is  set  free-that 
he  has  set  hirr  self  free-for  higher  dreams,  for  greater  privileges  [Ref.  10]. 

There  are  several  reasons  associated  with  the  human  need  to  hold  on  that 

Tannenbaum  discusses  in  his  book  on  the  subject.  Four  specific  points  about  holding  on 

made  by  Tannenbaum  are  [Ref.  1 1]: 

•  Change  is  loss.  All  change  requires  letting  go  of  the  familiar  and  predictable. 
Emotions  normally  associated  with  loss  include  anger,  guUt,  grief,  helplessness, 
hopelessness,  and  depression. 

•  Change  is  uncertainty.  AU  change  requires  a  move  from  the  known  to  the 
unknown.  Past  experience  with  ambiguity  and  surprise  will  impact  attitudes 
toward  change.  Emotions  normally  associated  with  uncertainty  may  be  fear, 
panic,  dread  and  anxiety. 

•  Change  dissolves  meaning.  All  change  dissolves  some  past  meaning  in  the 
lives  of  people  experiencing  it.  That  meaning  may  or  may  not  be  replaced. 

This  is  directly  related  to  the  self  definition  people  receive  from  their  jobs. 
Emotions  normally  associated  with  loss  of  meaning  are  confusion,  anxiety, 
frustration,  boredom,  apathy  and  depression. 

•  Change  violates  scripts.  Scripts  are  the  deeply  held  plans  and  goals  for  our 
lives,  conscious  or  perhaps  unconscious,  that  form  our  approach  towards  life 
itself.  Change  can  represent  a  loss  of  this  script,  or  produce  unacceptable 
variations  on  his  script.  Emotions  normally  associated  with  this  loss  are  deep 
and  poweri'ul,  such  as  shame,  guilt,  and  rejection. 
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These  aspects  of  change  cause  powerful  emotional  responses  in  the  people  facing 
change.  It  is  natural  for  those  people  to  want  to  hold  on  to  the  old  ways,  the  things 
known.  People  want  the  predictability  and  security  of  the  familiar.  Even  though  the 
potential  for  improvement  is  being  forecast  with  the  change,  people  know  their  current 
needs  are  being  met  without  the  uncertainty.  By  holding  on,  people  can  avoid  having  to 
let  go  of  practices  that  made  them  comfortable,  and  avoid  the  risks  they  feel  are  inherent 
with  any  change.  The  change  doesn’t  have  to  be  major  to  cause  these  reactions.  Ask  any 
manager  who  has  rearranged  a  work  space  about  people’s  reaction  to  that  minor  change. 

3.  Transition  Versus  Change 

Some  theorists  in  organizational  development  would  take  issue  with  the  semantics 
of  Hoffman’s  earlier  quotation.  Bridges  would  argue  that  the  real  fear  is  not  of  change, 
but  of  the  transition  itself.  He  feels  that  people  are  more  open  to  the  idea  that  change 
must  occur,  but  it  is  the  transition  that  is  resisted.  “Change  often  starts  with  a  new 
beginning,  but  transition  must  start  with  an  ending-with  people  letting  go  of  old  attitudes 
and  behaviors  [Ref.  12].” 

The  leader  who  recognizes  the  dangers  of  transition,  and  incorporates  methods  to 
answer  those  dangers  in  his  plan  will  be  the  most  likely  to  succeed.  It  is  ironic  that 
planned  changes  to  the  structure  of  an  organization  are  carefuUy  thought  out,  while 
organizational  transitions  are  not.  To  manage  transition  properly.  Bridges  says  the  leader 
must  [Ref.  12]: 

•  Identify  the  impacts  of  the  planned  change 

•  Identify  the  individuals  most  affected  by  the  change 
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Assess  the  units  readiness  for  transition 


•  Analyze  tiie  political  implications  of  the  change 

•  Set  a  realistic  pace  for  transition 

•  Create  a  team  to  manage  the  transition 

•  Identify  new  skills  required  and  conduct  training 

•  Review  and  improve  communication  resources  of  organization 

•  Create  incentives  for  meeting  the  requirements  of  transition 

•  Plan  to  celebrate  the  different  phases  of  transition 

One  of  the  specific  tools  Bridges  uses  to  analyze  the  impact  of  the  transition  is  the 
transition  management  plan.  This  involves  forecasting  the  impact  of  the  transition 
methodically,  and  using  trained  organizational  development  specialists  to  prepare  the 
organization  for  the  difficult  transition  ahead.  If  the  resources  are  not  available  for  the 
services  of  such  a  specialist,  a  dynamic  leader  can  use  the  tools  and  guidelines  that  bridges 
proposes  to  help  lead  his  organization  through  the  transition  state.  Figure  9  depicts  a 
sample  tool  from  Bridges’  book  that  the  transition  leader  can  use  to  evaluate  the  impact  of 
loss  on  the  organization. 


What 

WHO 

Groups 

Individuals 

Outsiders 

You 

Turf 

Attachments 

Structure 

Future 

Meaning 

Control 

Identity 

Figure  9.  Impact  of  Loss  Matrix 
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By  taking  these  steps,  the  leader  can  account  for  the  effects  of  transition  and  help 
the  people  of  the  organization  to  better  cope  with  the  uncertainty  that  will  certainly  be 
produced  in  the  transition  state. 

4.  The  Transition  State 

In  planning  for  a  transition,  the  leader  should  dedicate  effort  to  considering  the 
effects  of  the  transition  state  [Ref.  13]: 

•  High  uncertainty,  low  stability 

•  High  level.s  of  perceptual  inconsistency 

•  High  emojonal  stress  on  the  people 

•  High  energy  (often  undirected) 

•  Control  becomes  a  major  issue 

•  Conflict  increases 

•  Past  patterns  of  behavior  become  explicitly  valued. 

Because  there  are  so  many  volatile  emotions  and  feelings  involved  in  managing  this 
state,  many  people  prefer  to  pretend  it  doesn’t  exist.  It  is  much  easier  to  dismiss  the 
requirements  of  concerned  leadership  throughout  the  transition  state  as  “touchy-feeley” 
management.  Another  term  for  the  transition  state  is  the  “neutral  zone”.  The  failure  of 
traditional  management  training  to  properly  account  for  the  neutral  zone  has  handicapped 
the  ability  of  the  mangers  to  successfully  navigate  the  treacherous  gap  between  the  new 
ways  and  the  old  [Ref,  12].  The  plan  for  getting  through  transition  must  include  two  key 
areas.  It  must  provide  a  strategy  for  supporting  the  people  who  are  experiencing  the 
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emotional  symptoms  mentioned  earlier,  and  it  must  also  provide  a  mechanism  to  harness 
the  creativity  and  energy  that  will  be  produced  by  the  transition  itself. 

As  Bridges  states  in  his  book,  “K  all  of  this  sounds  a  little  strange  and 
unbusinesslike,  that  may  simply  show  why  so  few  businesses  manage  transition 
successfully.”  [Ref.  12]  Since  leaders  are  not  trained  in  how  to  manage  transition,  the 
instinct  is  to  get  through  it  as  quickly  as  possible,  and  not  dwell  on  the  feelings  of  people. 

One  of  the  painful,  yet  probable  realities  of  transition  is  that  there  may  be  people 
who,  no  matter  what  steps  are  taken  by  the  leaders  of  the  change,  will  not  be  able  to 
adapt.  Leaders  must  be  willing  to  acknowledge  this,  and  transfer  or  termination  of 
employment  of  these  individuals  may  be  best  for  them  and  the  organization  in  transition.  It 
is  important  to  recognize  these  people  as  early  as  possible,  because  depending  on  their 
social  capital  in  the  organization,  they  may  become  leaders  of  resistance  that  might 
possibly  prevent  or  sabotage  the  transition. 

5.  Training  for  Transition 

One  of  the  easiest,  yet  frequently  missed  steps  in  planning  for  transition  is  the  step 
of  training.  The  identification  of  new  skill  sets  required  by  the  transition  will  enable  the 
planners  to  couple  required  training  with  the  people  who  will  be  expected  to  perform  new 
functions  as  a  result  of  the  change.  This  training  will  build  the  confidence  of  the  people  in 
transition,  help  them  to  see  the  benefits  of  the  new  system,  and  increase  the  likelihood  of 
success.  As  Bridges  says,“It  is  surprising  how  often  organizations  pay  a  great  deal  of 
money  for  new  equipment  and  refuse  to  pay  a  little  money  to  train  people  to  use  it 
properly  [Ref.  12].” 
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B. 


THE  HUMAN  FACTORS  OF  TRANSITION 


While  the  primary  focus  of  this  thesis  has  centered  on  technology  and  design 
issues,  it  would  have  been  incomplete  without  acknowledgment  of  the  human  factors 
which  have  shaped  the  evolution  of  some  of  the  decisions  that  were  made.  As  in  any 
project  which  wiU  change  a  person’s  environment,  there  has  been  some  resistance  to 
change  on  the  part  of  people  at  MCI.  While  this  is  an  expected  outcome  of  the  process, 
migration  planners  need  to  give  this  facet  of  the  project  due  consideration. 

1.  The  Psychology  of  Resistance  to  Change 

While  preparing  this  architectural  recommendation,  the  project  team  was  not  yet 
educated  in  the  psychology  of  resistance  to  change.  Bryant  has  identified  seven  factors 
that  influence  attitudes  towards  change: 

•  Basic  predisposition  to  change 

•  Personal  sense  of  security 

•  Prevailing  cultural  beliefs 

•  Extent  of  trust  and  loyalty 

•  Objective  historic  events 

•  Specific  apprehensions  and  expectations  about  the  particular  change  [Ref.  14] 

These  key  factors,  often  ingrained  from  a  very  early  age,  are  the  framework  around 

the  manner  in  which  any  person  will  deal  with  change.  If  these  factors  cannot  be 
incorporated  into  new  system  planning,  then  the  planners  should  not  be  surprised  or 
disappointed  when  “their  brilliant  ideas  and  logical  analysis  are  simply  rejected  [Ref.  14].” 
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2.  Classes  o^'  Personalities  With  Respect  to  Change 

It  is  now  well  documented  in  this  chapter  that  many  people  dislike  change.  The 
uncertainties  of  transition  bring  with  them  many  factors  that  merit  special  consideration  in 
order  to  properly  manage  the  transition  effort.  By  addressing  the  type  of  change  attitude 
held  by  key  people,  their  attitudes  can  be  incorporated  into  the  transition  plan  and, 
hopefully,  either  converted  to  believers  in  the  new  system  or  at  least  neutralized  in  the 
damage  they  cause  to  the  transition  effort.  According  to  Shaffer  and  Simon,  people  fall 
into  five  classes  regarding  change  [Ref.  15]: 

•  Change  p'  sitive  -  excited  about  change,  welcome  it  in  all  forms.  Very 
rare. 

•  Change  neutral  -  no  strong  opinions,  go  with  the  flow,  adapt  to  the 
organization.  Not  a  change  leader,  but  not  an  enemy  either. 

•  Change  reluctant  but  open  minded  -  large  category  of  people.  May 
champion  the  status  quo  until  it  is  obvious  that  a  change  is  occurring. 

Often  a  good  balance  to  change  positive  people  because  they  are  more 
skeptical.  Can  be  convinced  of  the  merits  of  new  systems  with  proper 
groundwork. 

•  Change  combative  -  Strong  personalities  in  the  organization.  Typically 
have  invested  significant  time  in  getting  the  organization  to  its  current 
state.  Quick  to  decry  the  merits  of  any  change.  It  is  very  possible  that 
these  personalities  will  not  be  able  to  adapt  to  the  changes  required  to 
progress. 

•  Change  progressive  but  agenda  driven  -  Very  harmful.  Appear  to 
support  the  transition,  but  are  guided  by  personal  agendas  not  known 
to  the  planner. 

By  becoming  familiar  with  these  classes  of  attitudes,  identifying  where  key  people 
fit  in  to  these  classes,  and  preparing  for  ways  to  address  the  concerns  and  fears  of  these 
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people,  the  planner  can  reduce  the  impact  of  change  resistance  on  the  migration  to  a  new 
system. 

C.  TRANSITION  AT  MCI 

With  the  theoretical  foundation  for  understanding  transition  established,  analysis  of 
the  applicability  of  that  foundation  to  the  MCI  project  is  the  next  logical  step.  In 
retrospect,  the  human  factors  of  this  project  were  the  most  important.  The  inexperience 
of  the  project  team  in  anticipating  the  impact  of  the  human  factors  contributed 
significantly  to  the  learning  process  for  the  team.  In  the  sections  that  follow,  some  of  the 
specific  issues  of  change  that  impacted  this  study  will  be  discussed. 

1.  “Holding  On”  to  the  Minicomputer 

Much  of  the  senior  leadership  of  the  MIS  section  of  MCI  has  spent  their  entire 
career  operating  mainframes  and  minicomputers.  For  many  people,  the  idea  that 
microcomputers  are  now  as  powerful  as  the  venerable  minicomputer  is  very  difficult  to 
accept.  The  experience  base  of  knowledge  and  personal  credibility  in  the  organization  is 
tied  directly  to  the  organizational  power  that  generates  from  the  ability  to  operate  the 
minicomputer.  Transition  to  a  microcomputer  based  system  puts  the  senior  leaders  in  the 
position  of  knowing  no  more,  or  perhaps  even  less  than  their  subordinates.  This  potential 
loss  of  credibility  is  significant  incentive  to  “hold  on”  to  the  old  system  architecture.  In 
interviewing  MIS  personnel,  many  comments  were  made  about  the  old  system  being  good 
enough,  how  there  was  no  need  to  change  the  minicomputer  out,  and  how  the  operating 
system  and  developmtmt  environment  was  fine  for  the  need  of  the  system.  All  of  these 
rationalizations  indicate  a  strong  tendency  to  “hold  on”  to  the  old  ways. 


88 


2.  Loss  of  Turf 


Closely  related  to  the  need  to  hold  on  is  the  loss  of  turf  that  is  associated  with 
giving  up  the  sole  control  of  a  centralized  computer  system.  The  “turf’  for  the  context  of 
this  discussion  is  the  control  of  the  system.  If  the  system  is  transitioned  to  a 
microcomputer  environment  with  a  common  network  operating  system,  the  networking 
section  would  be  better  suited  to  run  the  system:  The  MIS  section  would  be  left  with  no 
real  duties.  This  is  a  ::iss  of  turf,  and  along  with  it,  potential  loss  of  job  security. 

3.  Required  Training  for  Transition 

There  are  numerous  opportunities  for  training  to  ease  the  burden  of  transition. 
Training  for  personnel  in  the  selected  database  is  available  to  ease  the  fear  of  moving  to  a 
new  DBMS,  and  as  Chapter  Vn  will  point  out,  if  a  planned  migration  is  implemented, 
training  in  the  end  state  operating  system  and  hardware  could  begin  immediately.  The 
overall  strategy  of  training  is  to  reduce  the  fear  of  the  new  system  by  increasing  staff 
familiarity  with  it. 

4.  Analysis  of  the  Key  Personnel  Classes 

The  predominant  personality  class  that  was  faced  at  MIS  in  developing  a  system 
architecture  was  the  “Change  progressive,  but  agenda  driven  personality  type”.  From  the 
outset  of  this  project,  MIS  planners  at  MCI  had  intended  to  conduct  a  modest 
improvement  in  the  existing  database  system,  without  addressing  the  rest  of  the 
architecture.  Further  study  of  the  proposal  and  involvement  of  Training  and  Education 
(T&E)  Division  at  Marine  Corps  Combat  Development  Command  forced  MCI  to  consider 
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a  more  in  depth  analysis  and  design  effort.  To  get  funding  to  move  forward  with  the 
project,  MCI  was  forced  to  solicit  involvement  of  the  Naval  Postgraduate  School. 

By  the  time  NPS  had  formed  a  project  team  and  had  begun  initial  analysis  of  the 
project,  the  current  state  of  customer  service  at  MCI  was  receiving  very  high  levels  of 
attention  from  the  Commandant  of  the  Marine  Corps.  The  time  frame  required  by  the 
NPS  project  team  to  conduct  the  analysis  provided  MCI  with  enough  breathing  room  to 
conduct  some  modifi  :  rations  to  customer  service  problems  which  reduced  the  level  of 
command  attention  dh  ected  at  MCI. 

The  level  of  cooperation  received  by  the  project  team  shifted  dramatically  late  in 
1996.  It  became  obvious  to  the  team  that  there  were  other  agendas  that  were  being 
addressed  outside  the  redesign  effort.  Return  of  information  that  had  been  promised  for 
September  in  order  to  meet  a  December  deadline  was  not  forthcoming  until  January,  after 
the  deadline  had  passed.  Information  necessary  for  the  completion  of  phases  of  the 
project  was  delayed  inordinately  without  justification.  Major  decisions  affecting  the 
architecture  were  made,  and  the  project  team  was  not  included  in  the  decision,  nor  briefed 
after  the  decision  had  been  made.  The  agendas  that  were  driving  the  actions  of  the  key 
players  in  this  process  are  not  as  salient  as  the  fact  that  these  agendas  existed  and  were  a 
major  shaping  force  in  the  outcome  of  the  project. 

As  a  final  note  on  the  impact  of  transitional  factors  on  this  project,  the  NPS  project 
team  recommended  option  one,  with  a  phased  migration  to  option  three.  MCI  chose  to 
pursue  option  two  as  an  architectural  solution.  The  choice  of  this  architecture  is 
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attributed  to  the  hidden  agendas  of  the  key  MIS  decision  makers,  and  is  not  recommended 
by  the  NPS  team  as  the  optimal  solution. 

D.  RECOMMENDATIONS  FOR  MCI 

There  are  many  facets  of  transitional  management  to  address.  The  recognition  that 
any  area  of  transitional  management  should  be  considered  is  to  the  credit  of  a  migration 
planner.  Key  areas  of  transitional  awareness  that  should  be  addressed  for  their  impact  on 
the  migration  effort  include  the  relationships  of  key  staff  members,  conflict  management, 
internal  communicat  cns,  social  structure  and  culture  of  the  workplace,  dominant 
coalitions  between  workers,  rewards  or  incentives  for  transition,  integrating  mechanisms 
to  facilitate  the  transition,  worker  input  to  the  transition  process,  and  worker  attitudes 
toward  change. 

There  are  several  steps  that  can  be  taken  by  the  transition  planner  to  address  the 
human  element  of  change.  These  include  education,  developing  and  obtaining  the  support 
of  senior  leadership,  getting  the  users  of  the  system  involved  in  the  development, 
rewarding  those  who  support  the  change  and  those  who  change,  using  the  change  as  a 
mechanism  to  support  career  enhancement  for  the  system  users. 

The  leader  can  complete  transition  training,  or  educate  himself  on  organizational 
development  techniques  so  that  training  in  the  expectations  of  transition  itself  can  be 
conducted  for  the  unit.  Education  in  the  mechanics  and  characteristics  of  humans  that  are 
undergoing  change  is  a  useful  undertaking  for  the  transition  leader.  By  acknowledging  the 
human  factor  in  the  success  of  a  migration  and  transition  effort,  the  project  manager  can 
begin  to  increase  the  success  probability  by  managing  the  risk  associated  with  the  human 
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element  of  the  transition.  MCI,  like  most  military  organizations,  has  a  change  resistant 
culture  and  many  of  vhs  IS  staff  are  change  reluctant  or  change  combative.  MCI  leadership 
can  ease  the  transition  to  MCIAIS  II  and  improve  the  likelihood  of  success  by  recognizing 
these  human  factors  and  working  with  the  key  change  resistors. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  objective  of  this  chapter  is  to  summarize  the  research  and  results  of  this  thesis, 
present  conclusions,  and  suggest  recommendations.  It  is  organized  into  three  sections. 
Section  A  provides  a  summary  of  the  research  effort.  Section  B  examines  the  issues  and 
conclusions  raised  through  the  use  of  the  methodology,  and  Section  C  provides  some 
recommendations  for  MCI  that  resulted  from  this  study. 

A.  SUMMARY  OF  RESEARCH 

As  a  part  of  a  larger  project,  this  study  began  in  August  1996  in  response  to  a 
request  from  the  Marine  Corps  Institute  to  determine  the  feasibility  and  requirements  for  a 
new  information  system  for  MCI.  The  primary  objective  of  this  thesis  is  to  develop  a 
technology  architecture  to  support  the  information  systems  of  MCI  and  to  address  the 
complex  technical  an- !  human  resource  issues  of  migration  from  the  current  legacy  system 
to  the  new  one. 

To  achieve  the  objective,  this  research  addressed  the  requirements  of  a  technology 
architecture  for  MCI,  following  Spewak’s  Enterprise  Architecture  Planning  methodology. 
Additionally  a  plan  for  system  migration  was  developed  using  the  guidelines  for 
incremental  migration  proposed  by  Brodie  and  Stonebraker. 

B.  ISSUES  AND  CONCLUSIONS 

1.  Research  Questions  Revisited 

In  Chapter  I,  the  thesis  raised  several  central  research  questions.  Answers  to  these 
questions  as  a  result  of  conducting  this  research  are  discussed  below. 
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1.  Can  a  technology  architecture  be  developed  to  support  the  current  and  future 
needs  of  the  Student  Services  Department  at  the  Marine  Corps  Institute? 

There  is  a  number  of  technical  solution  options  that  could  support  the  needs  of 
SSD.  These  options  were  discussed  in  detail  in  Chapter  IV.  The  recommended 
technology  architecture  is  based  on  a  detailed  analysis  of  technology  and  the  environment 
at  MCI,  and  is  summarized  in  the  following  section. 

2.  Can  exisricg  hardware  and  software  used  by  the  Student  Services  Department 
of  the  Mar  ne  Corps  Institute  be  successfully  migrated  to  an  open  system 
architecture? 

The  incremental  strategy  for  migration  proposed  in  Chapter  V  presents  a  plan  that 
offers  a  migration  strategy  with  the  highest  probability  of  success.  If  MCI  adopts  an 
incremental  plan,  thus  resisting  the  desire  to  conduct  “cold  turkey”  migration,  it  will 
significantly  increase  the  likelihood  of  a  successful  transition. 

3.  Can  Enterprise  Architecture  Planning  support  all  the  necessary  requirements  of 
this  transition? 

EAP  methodology  provides  for  the  definition  of  a  technology  architecture  within 
the  definition  of  an  O'  erall  system.  As  a  methodology,  it  includes  guidelines  for 
implementing  the  plan  and  for  managing  the  transition  effort.  It  is  weak,  however,  in  the 
details  of  a  migration  strategy.  For  this  reason,  the  incremental  strategy  developed  by 
Brodie  and  Stonebraker  was  used  to  complement  EAP  in  the  area  of  migration. 

4.  What  is  the  current  state  of  the  Marine  Corps  Institute  Automated  Information 
System  (MCIAIS)? 
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The  state  of  the  current  system  was  presented  in  detail  in  Chapter  III.  Appendix  A 
also  provides  a  complete  summary  listing  of  the  hardware,  software,  and  network 
components  of  the  current  system.  As  discussed,  the  system  is  barely  meeting  the  current 
needs  of  MCI,  and  requires  extraordinary  maintenance  efforts  to  meet  even  simple 
business  changes.  The  lack  of  usable  data  models  or  process  models  compounds  the 
problem  of  maintaining  and  evolving  the  system. 

5.  What  combinations  of  hardware  and  software  should  be  used  to  meet  new 
system  requirements  within  the  given  fiscal  limitations? 

There  are  many  possible  options  of  hardware  and  software  combinations  that  could 
significantly  improve  the  current  state  of  the  information  system.  Any  selected  option 
should  support  contemporary  principles  of  developing  hardware  architectures  as  outlined. 
MCI  can  build  upon  the  proposed  data  and  process  models  to  design  and  implement  a 
contemporary  information  system  that  provides  improved  flexibility  and  customer  support. 

2.  Research  Issues 

The  methodology  used  for  this  study  was  designed  to  be  used  by  people  trained -in 
the  techniques  of  EAP,  with  the  proper  time  and  tools  to  undertake  a  major  enterprise 
design  effort.  If  conducted  correctly,  EAP  appears  to  be  a  strong,  methodical  approach 
with  which  to  address  the  development  of  a  new  information  system.  The  detail  and 
processes  of  EAP  were  impressive.  It  is  a  useful  approach  to  system  development  and 
merits  consideration  bv  anyone  undertaking  a  system  development  project. 

The  problems  of  implementing  EAP  as  a  methodology  became  immediately 
apparent  in  the  genesis  of  this  study.  The  team  chosen  for  the  project  was  not  trained  in 
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EAP  techniques.  Because  it  was  an  academic  undertaking,  there  was  an  expectation  that  a 
significant  portion  of  the  project  itself  would  involve  a  learning  curve  on  the  part  of  the 
team  members.  Additionally,  the  scope  of  the  study  was  below  what  was  required  for 
EAP.  Spewak  clearly  states  “Despite  the  best  of  intentions,  and  the  intuitive  appeal  of 
dividing  EAP  along  departmental  lines  and  subsequently  combining  or  integrating  them, 
experience  has  show.;  chat  this  does  not  happen  successfully”  [Ref.  1].  The  scope  of  this 
study  was  clearly  set  r  elow  the  enterprise  level  and  therefore,  by  Spewak ’s  own 
estimation,  headed  for  trouble. 

The  third  departure  from  the  EAP  methodology  was  the  order  of  definition  taken 
by  the  team.  The  database  model  was  developed  before  the  business  functions  were 
defined,  not  after  the  business  process  definition  as  proscribed  by  the  methodology.  The 
impact  of  this  departure  has  not  yet  been  evaluated. 

Finally,  the  geographic  separation  and  poor  communications  between  the  project 
team  and  MCI  were  problematic.  The  methodology  requires  a  close  working  relationship 
with  a  high  level  of  feedback  and  interaction  between  the  project  team  and  the  supported 
enterprise.  Competing  priorities  and  physical  separation  made  this  essential  requirement 
difficult. 

C.  RECOMMENDATIONS 

The  completion  of  this  research  culminates  in  specific  recommendations  for  MCI 
with  regard  to  the  hardware,  software,  and  migration  to  the  a  new  system.  Many  factors 
were  considered  in  the  development  of  these  recommendations.  Standards  were  applied 
where  required,  industry  trends  were  analyzed  and  interpreted  for  their  applicability  to  this 


96 


project,  and  the  preferences  of  the  MIS  users  at  MCI  were  given  heavy  consideration. 

The  impact  of  change  management  issues  was  also  considered  and  the  eventual 
recommendations  include  the  impact  of  these  issues. 

1.  Technology  Recommendations 

The  principle  concern  in  recommending  a  technology  architecture  is  its  likelihood 
of  success/risk  of  faiicre.  A  microcomputer  based  hardware  platform  operating  Windows 
NT  (as  represented  by  the  third  option  discussed  in  Chapter  IV)  best  conforms  with  the 
developmental  principles  guiding  this  study.  It  is  therefore  the  preferred  choice  for  long 
term  success,  but  the  current  capabilities  and  training  requirements  of  the  personnel  who 
will  be  required  to  implement  the  recommended  system  cannot  be  overlooked. 
Additionally,  a  microcomputer  based  option  represents  the  greatest  change  for  the  people 
of  MCI  and  therefore  possesses  an  increased  risk  of  failure  if  implemented  at  this  time. 

It  is  therefore  recommended  that  MCI  adopt  a  phased  approach  to  upgrade  the 
current  technology  platform.  The  first  phase  is  to  upgrade  the  current  HP  3000  minicom¬ 
puter  and  using  it  as  s  server,  installing  a  new  Oracle®  DBMS  under  the  current  MPE/DC 
operating  system,  and  replacing  the  current  dumb  terminals  with  Pentium  level  microcom¬ 
puter  clients.  The  architecture  of  this  option  adheres  to  the  majority  of  developmental 
principles  guiding  this  study  and  will  support  all  current  and  near  term  system  require¬ 
ments  for  MCI.  The  second  phase,  which  culminates  in  the  implementation  of  the  third 
option,  incrementally  migrates  MCIAIS  to  a  tmly  open  system  architecture  and  consists  of 
an  Intel-based  server  with  multiple  processors,  Windows  NT  operating  system,  Oracle® 
DBMS,  and  state-of-the-art  microcomputer  clients. 
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There  has  been  much  discussion  in  the  Marine  Corps  regarding  the  transition  of 
Marine  Corps  network  operating  systems  from  Banyan  Vines  to  Windows  NT.  If  this 
transition  occurs,  MCI  will  be  able  to  standardize  operating  systems  on  Windows  NT  and 
eliminate  the  high  overhead  cost  in  training  required  to  operate  the  proprietary 
Hewlett-Packard  operating  systems.  Standardized  training  in  the  use  of  common  • 
microcomputers  versi  s  diverse  computer  systems  is  an  important  benefit  of  this  option. 

2.  Migration 

a.  Continued  Migration 

One  of  the  keys  to  a  useful  information  system  is  its  flexibility  in  adapting 
to  new  business  requirements  and  conditions.  Information  system  planners  must  realize 
that  information  systems  can  no  longer  be  viewed  as  static.  IS  systems  must  be 
continually  evaluated  for  additional  migration.  It  is  not  a  matter  of  i/continued  migration 
is  necessary,  but  only  when  it  is  necessary  and  in  what  form  the  migration  will  take. 

The  migration  from  the  first  phase  system  to  the  second  phase  system  wiU 
be  much  simpler  than  the  initial  legacy  migration  because  it  will  involve  a  modular  design, 
the  same  DBMS  and  open  architectures.  By  incrementally  migrating  modules  to  the  client 
side  where  possible,  further  reductions  in  server  processing  loads  will  be  achieved.  By 
breaking  out  of  the  mainframe  paradigm  that  has  held  MCI  in  place  for  many  years,  MCI 
can  design  and  develop  a  system  that  will  be  responsive  to  future  requirements  instead  of 
addressing  past  technology  and  current  requirements. 

Due  to  a  reevaluation  of  the  implementation  timeline  by  MCI,  the  potential 
exists  to  adopt  this  interim,  incremental  migration  strategy  to  the  ultimate  recommended 
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architecture.  With  th.’  implementation  of  the  gateway  products  discussed  below,  and 
minor  hardware  upgrades,  it  is  believed  that  MCI  can  accomplish  all  of  the  requirements 
to  begin  a  satisfactory  transition  to  the  second  phase  of  MCIAIS.  We  strongly  believe 
that  this  option  is  the  most  cost  effective,  training  effective  and  consistent  alternative  to 
meet  the  stated  objectives  of  this  study.  The  migration  to  a  relational  database  on  the 
current  platform  is  a  natural  incremental  step  to  the  end  state  system.  This  phased 
approach  to  system  migration  is  integral  to  a  successful  transition  for  MCI. 

b.  Gateways 

During  the  evolution  of  this  project,  only  one  potential  commercial  solution 
has  been  found  for  the  nnigration  of  data  directly  from  a  Turboimage  database  to  an 
Oracle®  database,  addressing  the  current  needs  of  MCI.  This  potential  solution,  available 
from  Starvision  Inc.,  is  a  gateway  application  that  provides  an  out  of  box  gateway  solution 
for  Turboimage  to  Oracle®  translation.  There  are  two  variants:  the  unidirectional  gateway 
and  the  bi-directional  gateway.  The  unidirectional  gateway  allows  users  of  the 
Turboimage  applications  to  update  the  Oracle®  database  or  allows  users  of  the  new  GUI 
windows  based  applications  to  update  the  Turboimage  database,  but  not  both.  A 
bi-directional  gateway  is  required  to  get  a  bi-directional  functionality.  This  product 
provides  full  replication  of  data  and  best  supports  the  parallel  migration  plan  in  its  current 
form.  The  Starvision  product  was  developed  internally  for  Hewlett-Packard  and  has  been 
improved  and  marketed  separately  from  the  original  HP  product  line.  It  specializes  in 
MPE/iX  Turbolmag '  gateway  capability,  and  seems  to  be  the  most  logical  fit  for  the 
existing  requirement:  at  MCI. 
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Additional  advantages  of  this  product  on  a  HP  3000  include  significantly 
enhanced  system  performance  and  throughput  of  data  due  to  “Standby  Agents”.  These 
are  standby  processes  that  are  running  before  the  actual  requests  are  made  by  the  user. 
This  results  in  predefined  data  views  being  available  much  faster.  The  Starvision  gateway 
is  compatible  with  most  development  tools  chosen  for  client  side  development,  and  is  fuUy 
integratable  into  an  intranet  environment  due  to  its  open  system  design.  This  solution,  or 
any  other  gateway  that  will  support  this  type  of  gateway  requirement,  is  the  type  of 
middleware  needed  to  adopt  an  incremental  migration  from  the  current  database  to  an 
Oracle®  database  soliiion. 

c.  Human  Resources 

To  address  the  human  element  of  change  there  are  several  steps  that  can  be 
taken  by  the  transition  planner.  These  include  education,  developing  and  obtaining  the 
support  of  senior  leadership,  getting  the  users  of  the  system  involved  in  the  development, 
rewarding  those  who  support  the  change  and  those  who  change,  using  the  change  as  a 
mechanism  to  support  career  enhancement  for  the  system  users,  and  educating  the 
organization  in  the  characteristics  of  transition.  Key  areas  of  transitional  awareness  that 
should  be  addressed  for  their  impact  on  the  migration  effort  include  the  relationships  of 
key  staff  members,  conflict  management,  internal  communications,  social  structure  and 
culture  of  the  workplace,  dominant  coalitions  between  workers,  rewards  or  incentives  for 
transition,  integrating  mechanisms  to  facilitate  the  transition,  worker  input  to  the  transition 
process,  and  worker  attitudes  toward  change. 
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MCI,  like  most  military  organizations,  has  a  change  resistant  culture  and 
many  personnel  are  resistant  to  change.  By  recognizing  these  human  factors  and  working 
with  the  key  change  resistors,  MCI  leadership  can  ease  the  transition  to  the  next  phase  of 
MCIAIS  and  improve  its  likelihood  of  success. 
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APPENDIX  A  -  INFORMATION  RESOURCE  CATALOG 


In  each  of  the  following  sections,  the  first  part  of  the  section  will  contain  a  listing  of  the 
information  format  for  that  section.  The  remaining  parts  of  that  section  will  reference  the  format 
provided  for  that  section. 

A,  Applications 

1.  Format 

The  following  format  for  the  catalog  of  applications  is  used; 

a.  Name  of  application,  and  person  primarily  responsible  for  app. 

b.  Plain  language  definition  of  the  application  and  what  it  does 

c.  Whether  application  is  batch,  on-line  or  both 

d.  Time  frame  required  to  run  application 

e.  Frequency  of  application  run 

f.  Applications/software  that  must  be  run  before  other  applications  can  run 

g.  Applications/software  that  must  be  run  after  other  applications  have  been  run 

2.  Application  One 

a.  Biscom  Facsimile  Service,  SSgt  Broome 

b.  Receives  faxes  electronically  and  forwards  them  to  the  final  recipient  based  on 
4-digit  DMTF  routing  number  (if  included  by  sender  of  fax).  Sends  electronic 
faxes  originating  from  users’  personal  computer. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 
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f.  None. 


g.  None. 

3.  Application  Two 

a.  Source  Library  System  (SLS),  SSgt  Broome 

b.  Stores  electronic  versions  of  Unit  Activity  Reports.  When  a  unit  desires  to 
receive  their  UAR  electronically,  they  send  an  e-mail  request  to  the  SLS  for  the 
specify  -  UAR  they  want.  The  SLS  sends  them  an  e-mail  with  the  requested 
UAR  as  an  attachment. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 

f.  None. 

g.  None. 

4.  Application  Three 

a.  Plato  Self-Paced  Courseware,  SSgt  Broome. 

b.  Plato  is  a  personal  education  interactive  software  package  that  is  available  on 
MCI's  classroom  computers.  This  software  is  used  to  provide 
training/education  in  several  areas  (English,  Math,  History,  etc.)  and  is  used  by 
Course  Developers  to  polish  their  writing  skills  and  by  Marines  to  improve 
their  general  knowledge  and  prepare  for  ASVAB  tests. 

c.  On-line  CD-ROM  (CD-ROM  server). 

d.  Sub-second. 
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e.  As  required. 

f.  None. 

g.  None. 

5.  Application  Four 

a.  Lotus  SmartSuite  Self-Paced  Courseware,  SSgt  Broome. 

b.  Interactive  courseware  installed  on  one  classroom  computer  to  teach  MCI 
personnel  how  to  use  Lotus  SmartSuite  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 

f.  None, 

g.  None. 

6.  Application  Five 

a.  Sharkimail,  SSgt  Broome. 

b.  Windows-based  e-mail  handling  package  that  includes  messaging  rules  for 
VINES.  Run  by  users  from  LAN  server. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 

f.  None. 

g.  None 
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7.  Application  Six 

a.  NetCensus,  ver  2.80,  SSgt  Broome 

b.  Automated  LAN  hardware/software  inventory  system.  Periodically,  when  a 
user  logs  on  to  the  LAN,  his  PC’s  hardware  and  software  components  are 
automatically  inventoried  by  NetCensus.  NetCensus  resides  on  the  LAN 
servei  and  is  activated  at  an  interval  determined  by  LAN  Administrator 
(ISMO). 

c.  On-line 

d.  N/A  (no  user  interaction) 

e.  Periodically  (usually  once/week) 

f.  None 

g.  None 

8.  Application  Seven 

a.  Lotus  SmartSuite  (office  integrated  suite),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-lint. 

d.  Sub-second. 

e.  As  required. 

f.  None. 

g.  None. 
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9.  Application  ’:'>ight 

a.  Calendar  Creator  +  (calendaring),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 

f.  None. 

g.  None. 

10.  Application  Wine 

a.  Microsoft  Project  (project  management),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 

f.  None. 

g.  None. 

11.  Application  Ten 

a.  Fastrack  (project  management),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line 

d.  Sub-second. 

e.  As  required. 
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f.  None. 


g.  None. 

12.  Application  Eleven 

a.  IBM  Anti-Virus  (anti-virus),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-ILoo. 

d.  Sub-se  ;ond. 

e.  As  required. 

f.  None. 

g.  None. 

13.  Application  Twelve 

a.  Dekina  Form  Flow  (automated  forms),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  Asrec  nired. 

f.  None. 

g.  None. 

14.  Application  Thirteen 

a.  Netscape  (Internet  access),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 
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d.  Sub-Si  >;ond. 


e.  As  required. 

f.  None. 

g.  None. 

15.  Application  Fourteen 

a.  PKZIP  (file  compression),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-sv  cond. 

e.  As  required. 

f.  None. 

g.  None 

16.  Application  Fifteen 

a.  ABC  Flowcharter  (flowcharting),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 

f.  None. 

g.  None. 
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17.  Application  Sixteen 

a.  MTF  Editor  (naval  messages),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  ret]  lired. 

f.  None. 

g.  None. 

18.  Application  Seventeen 

a.  Reflections  (Hewlett-Packard  terminal  emulation),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 

f.  None. 

g.  None. 

19.  Application  Eighteen 

a.  Adobe  Photoshop  (graphics/desktop  publishing),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  required. 
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f.  None. 


g.  None. 

20.  Application  Nineteen 

a.  CorelDraw  (graphics),  SSgt  Broome. 

b.  Personal  productivity  software. 

c.  On-line. 

d.  Sub-second. 

e.  As  r.:c,  aired. 

f.  None 

g.  None. 

21.  Application  Twenty 

a.  VEFADDR  and  RUCMCC  Upload,  GySgt  Floyd. 

b.  Retrieves  most  recent  student  information  (SSN,  rank,  location,  etc.)  in  ASCII 
format  from  the  Marine  Corps  Total  Force  System  (MCTFS)  and  refreshes 
MCIAIS  student  database. 

c.  Batch 

d.  Part  1 :  7  hours.  Part  2:  30  mins 

e.  Every  third  nightly  cycle. 

f.  This  joO  can  be  run  independently  of  the  nightly  cycle  jobs  remaining  below.  It 
is  performed  in  two  parts:  the  first  part  transferring  the  dataset  containing  the 
information  from  MCTFS  to  MCI's  Hewlett-Packard  over  a  leased  line  circuit, 
and  the  second  part  overlaying  the  MCTFS  information  in  MCIAIS.  The  first 
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part  is  performed  during  the  day,  and  the  second  part  is  performed  during  the 
nightly  cycle. 

22.  Application  Twenty-one 

a.  jrDLYBKUP.JOB.MCIAIS,  GySgt  Floyd. 

b.  Makes  copies  of  all  input  files.  [Note:  The  MPE/ix  operating  system  does  not 
support  generation  datasets;  therefore,  it  is  not  easy  to  keep  several  months' 
worth  of  input  information  for  research  purposes.  We  could  do  this 
programmatically,  but  frankly  have  not  done  so  because  of  the  significant  effort 
involved.  A  desired  feature  in  the  "new  MCIAIS"  would  be  the  ability  to 
store  input  data  for  at  least  the  past  two  months  to  allow  us  to  research 
problem  transactions  as  necessary.] 

c.  Batch 

d.  1  min 

e.  Nightly 

f.  First  job  of  nightly  cycle 

g.  Must  run  before  JDAILYO 1 . JOB.MCIAIS 

23.  Application  Twenty-two 

a.  JDAILYO  1  .JOB.MCIAIS ,  GySgt  Floyd. 

b.  Purges  previous  night’s  enrollment,  status,  and  holdfile  batch  files  and 
repopulates  them  with  today's  input.  Processes  enrollment,  reenrollment,  and 
administrative  deletion  transactions.  Archives  address  file.  Produces 
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Enroliinent  Error  Report  and  Deputy  Director  Report  (sends  report  datafiles  to 
the  print  spool  to  be  printed  later  by  system  operator). 

c.  Batch 

d.  2-10  mins,  depending  on  amount  of  input 

e.  Nightly 

f.  Must  mn  after  JDLYBKUP.JOB.  MCIAIS 

g.  Must !  un  before  JDAILY2A.JOB.MCIAIS  (Mondays  only)  or 
JDAILY2B.JOB.MCIAIS  (Tues-Fri) 

24.  Application  wenty-three 

a.  JDAII.  Y2A.JOB.MCIA1S,  GySgt  Floyd 

b.  Runs  the  holdfile  program,  grading  program,  and  motivations  and 
disenroUments  program.  Updates  onhand  quantities  stored  in  the  Logistics 
AIS  database  (sub-database  of  MCIAIS).  Produces  the  Total  Enrollments 
report  and  Holdfile  report  (sends  report  datafiles  to  the  print  spool  to  be 
printed  later  by  system  operator). 

c.  Batch 

d.  7  mins 

e.  Mondays 

f.  Must  jin  after  JDAILYOl.JOB.  MCIAIS 

g.  Must  run  before  JDAILY03.JOB.MCIAIS 
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25.  Application  Twenty-four 

a.  JDAILY2BJOB.MCIAIS,  GySgt  Floyd 

b.  Runs  (he  holdfile  program  and  grading  program.  Updates  onhand  quantities 
stored  in  the  Logistics  AIS  database  (sub-database  of  MCIAIS).  Produces  the 
Total  ’enrollments  report  and  Holdfile  report  (sends  report  datafiles  to  the  print 
spool  to  be  printed  later  by  system  operator). 

c.  Batch 

d.  5  mins 

e.  Tuesdays  through  Fridays 

f.  Must  run  after  JD AILYO 1  .JOB.  MCIAIS 

g.  Must  run  before  JDAILY03.JOB.MCIAIS 

26.  Application  Twenty-five 

a.  JDAILY03.JOB.MCIAIS,  GySgt  Floyd 

b.  Creates  mailing  labels  (sends  label  datafile  to  the  print  spool  to  be  printed  later 
by  system  operator). 

c.  Batch 

d.  2-10  mins 

e.  Nightly 

f.  Must  run  after  JDAILY2A.JOB.  MCIAIS  or  JDAILY2B. JOB. MCIAIS 

g.  Must  run  before  JDAILY04.JOB.MCIAIS. 
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27.  Application  1  wenty-six 

a.  JDAILY04.JOB.MCIAIS,  GySgt  Hoyd 

b.  Creates  and  prints  student  status  cards  (R-6  Cards),  letters  notifying  students 
of  failed  exam  (R-69),  completion  certificates  and  letters  detailing  questions 
missed  and  their  correct  answers  (R-69),  and  mailing  labels  for  PME  program 
diplomas.  Creates  Daily  Stock  Status  Report,  Logistics  Required  Action 
Repor!.,  Logistics  Transaction  Report,  and  PME  Completion  Report.  Creates 
file  with  PME  diploma  information  to  be  printed  separately  by  SSD  on  HP 
Lascii?-t  printer.  (Sends  report,  label,  and  status  datafiles  to  the  print  spool  to 
be  printed  later  by  system  operator.) 

c.  Batch 

d.  6-10  mins 

e.  Nightly 

f.  Must  run  after  JDAILY03.JOB.  MCIAIS 

g.  Must  run  before  JDAILY05.JOB.MCIAIS 

28.  Application  Twenty-seven 

a.  JDAII  Y05.JOB.MCIAIS,  GySgt  Floyd 

b.  Creates  datafile  containing  enrollment,  completion,  and  disenrollment 
transa  .  lions  to  be  posted  to  the  MCTFS  ("D91 "  file).  Processes  MCTFS 
Advisory  file  errors  (the  Advisory  file  contains  MCI  transactions  that  failed  to 
post  in  the  previous  night's  cycle). 

c.  Batch 
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d.  1-10  mins 


e.  Nightly 

f.  Must  run  after  JDAILY04.JOB.  MCIAIS 

g.  Must  .un  before  JDAILY06JOB.MCIAIS 

29.  Application  Twenty-eight 

a.  JDAII.Y06.JOB.MCIAIS,  GySgtRoyd 

b.  Counts  exams  issued  during  cycle.  Creates  Exam  Total  report  (sends  report 
datafile  to  the  print  spool  to  be  printed  later  by  system  operator) 

c.  Batch 

d.  1-5  mins 

e.  Nightly 

f.  Must  ran  after  JDAILY04.JOB.  MCIAIS 

g.  Must  run  before  PARTBKUP.  JOB  .MCIAIS 

30.  Application  Twenty-nine 

a.  PARTBKUP.JOB.MCIAIS 

b.  Performs  partial  backup  of  MCIAIS  datafiles,  program  files,  and 
databases,  updating  any  changes  made  since  the  last  backup  of  any  kind. 

c.  Batch 

d.  60  -  90  mins 

e.  Nightl>  (except  Fridays  and  Monthlies,  when  full  backup  is  perfoimed) 

f.  Lastjcb  in  cycle 
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31.  Application  Thirty 

a.  J3633UA4.JOB.MCIAIS,  GySgt  Floyd 

b.  Creates  datafiles  containing  Unit  Activity  Report  (UAR)  data  such  as  RUC, 
SSN,  name,  etc.  (These  files  will  be  copied  onto  tapes  in  jobs 
FCOPYUA1.JOB.MCIAIS  through  FCOPYUA3.JOB.MCIAIS,  which  will  be 
downloaded  to  print  on  MCI's  Xerox  printer.) 

c.  Batch 

d.  8hrs 

e.  Mont.  L  y 

f.  Must  run  after  JDAILY06JOB.  MCIAIS 

g.  Must  run  before  J3633UB4.JOB.MCIAIS 

32.  Application  Thirty-one 

a.  J3633UB4.JOB.MCIAIS,  GySgt  Floyd 

b.  Creates  Monthly  Report  of  Operations,  Program  Enrollments  and  Completion 
report.  Answer  print.  Reference  print,  Air  Force  Completion  report.  Exam 
Totals  report  Logistics  AMRD  Variance  report.  Course  Data  File  Print, 
Command  and  Staff  Course  report,  and  RUCMCC  Listing  (sends  report 
datafiles  to  the  print  spool  to  be  printed  later  by  system  operator). 

c.  Batch 

d.  10  -  14  hrs 

e.  Monthly 
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f.  Must  lun  after  J3633UA4.JOB.MCIAIS 


g.  Must  run  before  J3633UC4.JOB.MCIAIS 

33.  Application  Thirty-two 

a.  J3633L!C4.JOB.MCIAIS,GySgt  Floyd 

b.  Archives  course  records  whose  date  of  latest  course  activity  is  greater  than  13 
months. 

c.  Batch 

d.  30  -  60  mins 

e.  MontlUy 

f.  Must  run  after  J3633UB4.JOB.MC1AIS 

g.  Must  run  before  FULLBACK.JOB.MCIAIS 

34.  Application  Thirty-three 

a.  J3633UC4.JOB.MC1A1S,  GySgt  Hoyd 

b.  Archives  course  records  whose  date  of  latest  course  activity  is  greater  than  13 
months. 

c.  Batch 

d.  30  -  60  mins 

e.  Monthly 

f.  Must  run  after  J3633UB4.JOB.MC1A1S 

g.  Must  run  before  FULLBACK.JOB.MC1A1S 
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35.  Application  Thirty-four 

a.  FULLBACKJOB.MCIAIS,GySgtnoyd 

b.  Performs  a  full  backup  on  entire  MCIAIS  (datafiles,  program  files,  and 
databases) 

c.  Batch 

d.  10  hours 

e.  Fridays  and  monthly 

f  Can  r.M  after  JDAILY06.JOB.MCIAIS  or  J3633UC4.JOB.MCIAIS 
g.  Must  run  before  Electronic  UAR  Process  (JUSLS.JOB.MCIAIS) 

36.  Application  Thirty-five 

a.  JUSLS JOB.MCIAIS,  GySgt  Hoyd 

b.  Sets  up  file  fi'amework  for  electronic  UARs. 

c.  Batch 

d.  20  mins 

e.  Twice  monthly 

f  Can  run  after  FULLBACKJOB.MCIAIS,  but  is  independent  of  the 
monthly  closeout  cycle  process, 
g.  Must  tun  before  J36330LU.JOB.MCIAIS 

37.  Application  Thirty-six 

a.  J36330LU.J0B.MCIAIS,  GySgt  Floyd 

b.  Populates  the  electronic  UAR  framework  set  up  in  JUSLS.JOB.MCIAIS  with 
student/course  information. 
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Batch 


c. 

d.  8-10  hrs 

e.  Twice  monthly 

f.  Must  run  after  JUSLSLJOB.MCIAIS 

g.  Last  job  in  electronic  UAR  creation  process.  The  datafile  created  in  this  job  is 
then  moved  from  the  HP  to  one  of  the  LAN  servers  by  the  system  operator. 

38.  Application  Thirty-seven 

a.  FCOPYUAl.JOB.MCIAIS.GySgtHoyd 

b.  Copie.;  UAR  datafiles  created  in  J3633UA4.JOB.MCLAIS  to  Tape  1 
(approximately  500,000  student  records). 

c.  Batch 

d.  20  mins 

e.  Monthly 

f.  May  ran  after  J3633UA4.JOB.MCIAIS 

g.  Must  run  before  FCOPYUA2.JOB.MCIAIS 

39.  Application  Thirty-eight 

a.  FCOPYUA2.JOB.MCIAIS,  GySgt  Floyd 

b.  Copies  UAR  datafiles  created  in  J3633UA4.JOB.MCIAIS  to  Tape  2 
(approximately  500,000  student  records). 

c.  Batch 

d.  20  mias 

e.  Montlily 
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f.  Must  mn  after  FCOPYUA 1  JOB.MCIAIS 


g.  Must  run  before  FCOPYUA3.JOB.MCIAIS 

40.  Application  Thirty-nine 

a.  FCOPYUA3.JOB.MCIAIS,  GySgt  Royd 

b.  Copies  UAR  datafiles  created  in  J3633UA4.JOB.MCIAIS  to  Tape  3 
(appro  - imately  500,000  student  records). 

c.  Batch 

d.  20  min 

e.  Monthly 

f.  Must  run  after  FCOPYUA  1  .JOB.MCIAIS 

g.  Last  job  in  monthly  cycle. 

41.  Application  Forty 

a.  PART  1  (JBAGTFLE. JOB.MCIAIS),  GySgt  Royd 

b.  Job  JBAGTFLE.JOB.MCIAIS  creates  ASCII  file  on  HP.  System 
operator  then  FTPs  it  to  Conversant  over  the  LAN. 

c.  Batch 

d.  3  -4  hrs 

e.  Once  per  week 

f.  First  j  ob  in  process 

g.  Must  run  before  processes  in  Part  2  (below)  are  started. 
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42.  Application  f  orty-one 

a.  PART  2  (Conversant  Load),  GySgt  Floyd 

b.  System  operator  logs  onto  Conversant  system  and  downloads  datafile  that  was 
FTP-ed  in  Part  1  (above)  onto  Conversant  database. 

c.  Batch 

d.  30  mins 

e.  Once  per  week 

f.  Must  "un  after  Part  1  (above) 

g.  Last  job  in  Conversant  database  update  process 
B.  HARDWARE 

This  section  contains  a  brief  description  of  major  hardware  items  in  the  current 
information  system. 

1.  Servers 

Three  Dell  PCs  located  at  MCI  on  the  Washington  Navy  Yard  (two  are  486-66s  w/32MB 
memory  and  7.5GB  disk  arrays;  one  is  a  80586-60MHz  w/64MB  memory  and  8GB  disk  array). 
Two  Dell.  PCs  located  at  the  Maxine  Barracks  Washington  DC  (one  is  a  486-66  w/32MB  memory 
and  7.5GB  disk  array;  one  is  a  80586-60MHz  w/64MB  memory  and  8GB  disk  array).  These 
servers  contain  file,  print,  and  e-mail  services  for  MCI  and  Post  users.  All  servers  run  Banyan 
VINES  version  6.3(0).  lach  is  Single  Attached  Station  (SAS)-connected  to  a  FDDI  backbone 
for  server-to-server  traffic ,  and  has  a  separate  lOMBS  ethemet  connection  for  user  traffic.  The 
topology  is  Ethernet,  using  Cat  5  UTP  cabling,  with  remainder  using  thin  ethernet  cabling  (to  be 
replaced  with  Cat  5  UTP  cabling  by  Apr  97). 
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2.  Network  communication  platforms 

Two  Cableton  MMAC-8  Hubs,  with  one  management  module  (w/SNMP)  per  hub,  four 
24-port  lObaseT  ethernet  modules  for  user  ports  per  hub,  and  one  FDDI  module  per  hub  (four 
S  AS  ports,  one  DAS  port  -  the  three  LAN  servers  located  at  MCI  are  each  attached  to  the  FDDI 
module  via  one  of  the  SAS  ports). 

One  AirLan/Bridge,  with  Antenna,  Long  Range,  1  Idb  directional  wireless  connection 
between  MCI  Server  1  and  MarBks  Server  1  (2  MBS  data  transfer  rate,  spread- spectrum 
transmission,  900  MHz  bandwidth,  rapid  switching  between  channels). 

3.  Microcomputers 

There  is  a  mixture  of  80386,  80486,  and  80586.  By  mid- 1997,  most  microcomputer 
platforms  at  MCI  will  be  80586-90MHz-i-  with  16-40MB  RAM,  1.2-t-GB  hard  drives,  Windows 
95.  No  80386-based  micros  will  remain  in  service.  There  will  be  (18)  80586s  in  SSD,  and  (7) 
80586s  in  Logs.  MCI  prefers  to  keep  Win95  on  user  ("client")  microcomputers,  and  use 
WindowsNT  as  the  operating  system  for  application  servers  —  or  users  running  high-end  PC 
applications. 

4.  Minicomputer 

Hewlett-Packard  3000,  Series  957SX  (HP  Prod  No.  3265  IB)  w/160MB  memory 

5.  Input  Devices 

a.  Scanners:  One  360  DPI,  One  600  DPI 

b.  Digital  Camera:  One  Kodak  Digital  Camera  System 

c.  Tape  Drive:  6250/1600  cpi  Streaming  Tape  Drive  (HP  Prod  No.  7978B) 
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d.  Scaniw^r:  National  Computing  Systems,  model  Op7-35,  Dual  Ink  Scanner. 
Exam  answers  are  scanned  from  DP-37  input  forms  onto  diskette,  which  are 
then  read  into  the  nightly  cycle  and  processed  by  the  MCIAIS  grading 
application. 

e.  Hewlett-Packard  Terminals  or  PC  Terminal  Emulation  (HP  Prod  No.  2392A) 

6.  Output  &  Graphic  Displays  (printers) 

a.  Hewk  ,t-Packard  LaserJet  3  (personal  printer)  -  total  MCI  quantity:  9  (1  in 
SSD,  2  in  Logs) 

b.  Hewl(  !:-Packard  LaserJet  3si  (personal  printer)  —  total  MCI  quantity:  1  (1  in 
Logs) 

c.  Hewlett-Packard  LaserJet  4  (personal  printer)  —  total  MCI  quantity:  20  (1  in 
SSD,  0  in  Logs) 

d.  Hewlett-Packard  LaserJet  4si  (network  printers)  -  total  MCI  quantity:  5  (1  in 
SSD,  0  in  Logs) 

e.  Hewlett-Packard  Line  Printer  (One)  1600  LPM  Line  Impact  Printer  (HP  Prod 
No.  2567C) 

f.  Xerox  Line  Printer  (One)  Model  4850  Laser  Printer  (prints  black  and  one  other 
color .'  200,000  impressions/mo  capacity) 

7.  Plotters 

None 
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8.  Storage  Media  (disks,  cd's,  tape,  etc.) 

a.  CD-Rom  Tower  with  capability  for  six  CD-ROMs  and  one  rewriteable 
CD-opiical  disk  for  off-line  storage  of  MCI  course  materials.  CD-ROMs  are 
now  2x,  but  are  planned  to  be  upgraded  to  8x  in  mid-97. 

b.  (One)  Series  6000  SCSI  Mass  Storage  System  (HP  Prod  No.  C3023R),  which 
contains  (four)  2GB  disk  drives. 

c.  (Two)  2GB  full  height  SE  SCSI  disks  (HP  Prod  No.  A2446A) 

d.  (One)  2GB  DDS  DAT  Drive  (HP  Prod  No.  C2477SZ) 

9.  Automated  Voice  Response  (AVR)  System 

AT&T  Intuity  Conversant  System,  version  5.0.  Conversant  is  an  AVR  system  that 
connects  to  part  of  MCI's  telephone  PBX  system  (AT&T's  Merlin  Legend  IS-3)  [There  are  two 
Merlin  Legends  in  MCI’s  PBX  system  -  one  is  a  Merlin  Legend  IS-3  and  the  other  is  a  Merlin 
Legend  Intuity].  Callers  to  MCI  are  greeted  by  a  recorded  voice  from  the  Merlin  PBX  and  are 
offered  several  choices  -  one  of  them  being  to  access  the  Conversant  AVR  system  to  listen  to  a 
readout  of  student  activity  in  MCI  courses.  If  they  desire  to  use  the  AVR  system,  they  are 
prompted  to  enter  the  student's  SSN  and  the  course  number  for  which  they're  interested  in 
receiving  status. 

MCI  wiU  soon  expand  the  capabilities  of  this  system  so  that  it  will  allow  up  to  12  callers  to 
access  it  at  a  time  (vice  the  current  6).  Additionally,  we  desire  to  use  Conversant  as  another 
method  for  Marine  students  to  enroll  in  MCI  courses. 

Currently,  Conversant  resides  on  an  AT&T-proprietary  hardware  platform  (80386-based 
MAP/IOOC  platform,  l.iCrB  hard  drive,  32M  RAM),  running  under  UNIX  System  5,  version  4.0. 
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There  is  an  Oracle  6  relational  database  installed  on  this  platform,  but  it  was  never  intended  to 
handle  the  amount  of  student  data  we're  loading  into  it.  The  database  takes  so  much  disk  space 
that  basic  Conversant  management  programs  have  been  removed  to  make  room  for  this  data. 

To  restore  these  management  programs,  MCI  is  standing  up  a  standalone  PC  (80586,  Windows 
NT  0/S,  Oracle?  RDB)  that  wiU  have  the  capacity  to  handle  just  MCI's  student  data  in  its 
database.  Conversant  wih  then  access  student  data  on  this  standalone  database  upon  caller 
demand.  This  will  free  uj)  the  necessary  space  in  Conversant  to  restore  its  original  functionality 
(Conversant  was  never  .  Icsigned  to  hit  against  a  relational  database  installed  on  its  own  hard  disk). 
Conversant  is  connected  i  o  the  HP  CPU  via  thin  ethemet  adapters  and  thick  ethemet  to  two 
MMAC-8  hub  ethemet  module  ports.  The  purpose  of  this  connection  is  to  transfer  student  data 
from  the  HP  to  the  Conversant  student  database.  This  update  occurs  once  per  week.  The  Merlin 
PBX  is  not  connected  to  the  HP  3000. 

10.  Planned  hardware  additions 

a.  24-porf  lOOMBS  switched  fast  ethemet  hub  for  application  server  traffic  and 
high-speed  connections  for  data  processing  personnel. 

b.  Remote  Access  Service  (RAS)  with  PPP  dial-in  through  Cisco  router  running 
on  Windows  NT  platform. 

C.  SOFTWARE 

1.  Operating  SyvStems 

a.  HP's  MPE/ix  (HP  Prod  No:  3265  IB),  version  5.5,  60-user  license 

b.  DOS  6.22 

c.  Windows  3.11 
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d.  Windows  95 


e.  Windows  NT  version  4.0 

2.  Database  Management  Systems 

a.  HP's  Turbolmage/XL  (prod  no:  B3524A),  Version  4.0,  60-user  license 

b.  HP’s  System  Dictionary  (Prod  No.  32256A)  —  data  dictionary 

c.  HP's  QueryA^  -  basic  query  application 

d.  Adagf  r  Corp's  Adapter/Manager  --  third-party  DBMS  tool  (more  powerful 
than  ItA'^'s  database  utilities) 

e.  Cognos  Corporation’s  Powerhouse  Dictionary  Language  (PDL),  ver  7.29.C 
creates  and  maintains  Powerhouse  data  dictionary. 

3.  Languages 

a.  HP’s  Transact/iX  (Prod  No.  30 138 A)  —  3GL  application  development 
language 

b.  Cognos  Corporation's  Powerhouse  4GL,  ver  7.29.C  -  4GL  application 
development  language 

c.  Cogn^js  Corporation’s  Quiz,  ver  7.29.C  —  report  and  query  writer 

d.  Cognos  Corporation's  QDesign,  ver  7.29.C  —  designs  screens  for  data  entry 
and  re  trieval 

e.  Cognos  Corporation’s  QTP,  ver  7.29.C  --  volume  transaction  processor  (can 
add,  change,  or  delete  large  amounts  of  data  quickly  and  efficiently) 
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4.  Other  Softwjire 


a.  HP's  Edit  3000—  line  editor  that  creates  and  manipulates  ASCII  files 

b.  HP's  TDP/3000  (Prod  No.  36578A)  —  full-screen  editor 

c.  HP's  GlancePlus  MPE/iX  (Prod  No.  B1787B)  —  performance  and  tuning  tool 
(installed  with  version  5.0  of  MPE/iX  O/S  in  winter  '95) 

d.  Performance  Software  Group's  Fastran  —  compiler  for  Transact  application 
development  language 

e.  Performance  Software  Group's  Facade,  ver  1.1  —  full-screen  co-editor 

f.  Dynamic  Info  Systems  Corporation's  Omnidex  —  3rd  party  indexing 

g.  Orbit  Software's  Backup4-/XL  —  high  speed  backup  utility 

h.  Lund  Performance  Solutions'  SOS  Performance  Advisor  for  HP3000 
(SOS/3000)  -  performance  and  tuning 

i.  Lund  Performance  Solutions'  DeffagX  -  disc  defragmentation  package 

j.  Diamond  Optimum  Systems  DOC  3000  —  scans  and  cross-references  source 
code  and  job  streams. 

k.  VE  Soft's  MPE/iX  3000  —  operating  system  utility  that  enhances  system 
management,  program  development,  and  console  operation  tasks. 

l.  VESoft's  Security  3000  —  system  security  package 

m.  VE  Soft's  VE  Audit  3000  —  security  reporting  package  (attempts  to  find 
loopholes  in  Security  3000  setup) 
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D.  COMMUNICATIONS 


1.  Signal  Devices 

a.  28.8KBS  Modems--  Currently,  five  dial-in  phone  lines  are  supported  by  MCI 
servers  1  and  2.  Three  of  these  five  lines  will  be  converted  to  PPP  connections 
via  a  Windows  NT  Remote  Access  Service,  to  be  attached  to  the  hub  via 
lOOMBS  ethernet  cabling 

b.  HP's  SupportLink  (HP50759B)  —  2400  dial-in  modem  (being  replaced  with 
higher-  speed  modem) 

c.  Motoi  Tla  CODEX  3500  —  modem/line  conditioner,  connects  to  56KB  circuit 

2.  Connections 

a.  From  MarBks/MCI  LAN  to  USMC  WAN/MCDN:  leased  56KB  circuit 
attached  between  MarBks/MCI  server  1  and  HQMC  server.  This  circuit  will 
be  upgraded  to  a  T1  attached  to  a  Cisco  4500M  router,  which  will  be 
SAS-attached  to  the  MarBks/MCI  LAN  server-to-server  FDDI  backbone. 
Note:  all  TCP/IP  traffic  to  the  Internet  shares  this  circuit  with  Banyan  VINES 
traffic. 

b.  From  MCI  to  KCMO:  56KB  dedicated  leased  line  (protocol  is  HP  SNA) 

c.  From  internal  LAN  PC  users  to  HP:  Ethernet  LAN,  "Reflections  for 
Wind  .■>ws"  terminal  emulation  software  (protocol:  VT  Manager),  soon  to  be 
Telnet-capable. 

d.  From  HP  to  Xerox  4850  Printer:  TCP/IP  connection,  using  PC  running 
interface  software  (interface  software  manufacturer:  Solimar). 
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e.  From  HP  to  AT&T's  Conversant  (Automated  Voice  Response  System):  thin 
ethemet  adapters  and  thick  ethernet  to  two  MMAC-8  hub  ethemet  module 
ports.  Planned  upgrade  to  100BaseT  cabling. 

3.  Network  communications 

a.  (One)  DTC72MX  Communication  Controller  (HP  Prod  No.  J2070A) 

b.  Hewlett-Packard's  NS3000  (Prod  No.  36920A)  -  allows  HP  3000  to 
communicate  with  other  computers  as  part  of  distributed  network.  MCI  uses 
the  following  modules: 

c.  SNA  Link/ix  (Prod  No.  30291A):  3270  connections  with  IBM  mainframe 

d.  SNA  NRJE  (Prod  No.  30292A):  print  services,  RJE 

e.  HP  Telnet^iX  :  telnet  capability  (planned,  not  in  use  yet) 

f.  SNA  IMF  Pass  Through:  passes  data  fm  HP  to  IBM  mainframe 

g.  LU6.?  API:  3270  emulation  through  HP 

h.  SNA  EvlF/iX  (Prod  No.  30293A) 

i.  ThinLAN  3000/iX  (36923A):  connection  into  Banyan  LAN 
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